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CHAPTER  1 
INTRODUCTION 


The  Ada  implementation  described  above  was  tested  according  to  the  Ada  Validation  Procedures 
[Pro92]  against  the  Ada  Standard  [Ada83J  using  the  current  Ada  Compiler  Validation  Capability 
(ACVC).  This  Validation  Summary  Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada 
implementation.  For  any  technical  terms  used  in  this  report,  the  reader  is  referred  to  [Pro92].  A 
detailed  description  of  the  ACVC  may  be  found  in  the  current  ACVC  User’s  Guide  (UG89]. 

1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada  Certification  Body  may  make 
full  and  free  public  disclosure  of  this  report.  In  the  United  States,  this  is  provided  in  accordance  with 
the  "Freedom  of  Information  Act"  (5  U.S.C.  #552).  The  results  of  this  validation  apply  only  to  the 
computers,  operating  systems,  and  compiler  versions  identified  in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report  do  not  represent  or  warrant  that 
all  statements  set  forth  in  this  report  are  accurate  and  complete,  or  that  the  subject  implementation 
has  no  nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of  this  report  are 
available  to  the  public  from  the  AVF  which  performed  this  validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 

Questions  regarding  this  report  or  the  validation  test  results  should  be  directed  to  the  AVF  which 
performed  this  validation  or  to: 

Ada  Validation  Organization 

Computer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria  VA  22311-1772 

1.2  REFERENCES 

[Ada83]  Reference  Manual  for  the  Ada  Programming  Language. 

ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987. 

[Pro92]  Ada  Compiler  Validation  Procedures. 

Version  3.1,  Ada  Joint  Program  Office,  August  1992. 

[UG891  Ada  Compiler  Validation  Canabilitv  User’s  Guide. 

21  June  1989. 
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1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC.  The  ACVC  contains  a 
collection  of  test  programs  structured  into  six  test  classes;  A,  B,  C,  D,  E,  and  L.  The  first  letter  of  a 
test  name  identifies  the  class  to  which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executable.  Class  B 
and  class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link  time,  respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and  produce  a  PASSED,  FAILED,  or 
NOT  APPLICABLE  message  indicating  the  result  when  they  are  executed.  Three  Ada  library  units, 
the  packages  REPORT  and  SPPRT13,  and  the  procedure  CHECK_FILE  are  used  for  this  purpose. 
The  package  REPORT  also  provides  a  set  of  identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test  objective.  The  package 
SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the  Ada  Standard.  The  procedure  CHECK  FILE 
is  used  to  check  the  contents  of  text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the 
Ada  Standard.  The  operation  of  REPORT  and  CHECK_FILE  is  checked  by  a  set  of  executable  tests. 
If  these  units  are  not  operating  correctly,  validation  testing  is  discontinued. 

Class  B  tests  check  that  a  compiler  detects  illegal  language  usage.  Class  B  tests  are  not  executable. 
Each  test  in  this  class  is  compiled  and  the  resulting  compilation  listing  is  examined  to  verify  that  all 
violations  of  the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada  code  which 
must  not  be  flagged  illegal  by  the  compiler.  This  behaviour  is  also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects  violation  of  the  Ada  Standard 
involving  multiple,  separately  compiled  units.  Errors  are  expected  at  link  time,  and  execution  is 
attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by  implementation-specific 
values  -  for  example,  the  largest  integer.  A  list  of  the  values  used  for  this  implementation  is  provided 
in  Appendix  A.  In  addition  to  these  anticipated  test  modifications,  additional  changes  may  be  required 
to  remove  unforeseen  conflicts  between  the  tests  and  implementation-dependent  characteristics.  The 
modifications  required  for  this  implementation  are  described  in  section  2.3. 

For  each  Ada  implementation,  a  customized  test  suite  is  produced  by  the  AVF.  This  customization 
consists  of  making  the  modifications  described  in  the  preceding  paragraph,  removing  withdrawn  tests 
(see  section  2.1),  and  possibly  removing  some  inapplicable  tests  (see  section  2.2  and  [UG89]). 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each  test  of  the  customized  test  suite 
according  to  the  Ada  Standard. 
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1.4  DEFINITION  OF  TERMS 


Ada  Compiler 


Ada  Compiler 
Validation  Capability 
(ACVC) 

Ada  Implementation 


Ada  Joint  Program 
Office  (AJPO) 

Ada  Validation  Facility 
(AVF) 

Ada  Validation 
Organization  (AVO) 

Compliance  of  an  Ada 
Implementation 

Computer  System 


Conformity 

Customer 


Declaration  of 
Conformance 


The  software  and  any  needed  hardware  that  have  to  be  added  to  a  given 
host  and  target  computer  system  to  allow  transformation  of  Ada 
programs  into  executable  form  and  execution  thereof. 

The  means  for  testing  compliance  of  Ada  implementations,  consisting  of 
the  test  suite,  the  support  programs,  the  ACVC  user’s  guide  and  the 
template  for  the  validation  summary  report. 

An  Ada  compiler  with  its  host  computer  system  and  its  target  computer 
system. 

The  part  of  the  certification  body  which  provides  policy  and  guidance  for 
the  Ada  certification  system. 

The  part  of  the  certification  body  which  carries  out  the  procedures 
required  to  establish  the  compliance  of  an  Ada  implementation. 

The  part  of  the  certification  body  that  provides  technical  guidance  for 
operations  of  the  Ada  certification  system. 

The  ability  of  the  implementation  to  pass  an  ACVC  version. 


A  functional  unit,  consisting  of  one  or  more  computers  and  associated 
software,  that  uses  common  storage  for  all  or  part  of  a  program  and  also 
for  all  or  part  of  the  data  necessary  for  the  execution  of  the  program; 
executes  user-written  or  user-designated  programs;  performs  user- 
designated  date  manipulation,  including  arithmetic  operations  and  logic 
operations;  and  that  can  execute  programs  that  modify  themselves  during 
execution.  A  computer  system  may  be  a  stand-alone  unit  or  may  consist 
of  several  inter-connected  units. 

Fulfilment  of  a  product,  process  or  service  of  all  requirements  specified. 

An  individual  or  corporate  entity  who  enters  into  an  agreement  with  an 
AVF  which  specifies  the  terms  and  conditions  for  AVF  services  (of  any 
kind)  to  be  performed. 

A  formal  statement  from  a  customer  assuring  that  conformity  is  realized 
or  attainable  on  the  Ada  implementation  for  which  validation  status  is 
realized. 


Host  Computer  System  A  computer  system  where  Ada  source  programs  are  transformed  into 

executable  form. 

Inapplicable  test  A  test  that  contains  one  or  more  test  objectives  found  to  be  irrelevant  for 

the  given  Ada  implementation. 


Validation  Summary  Report 


AVF_\'SR_90502/83 


EDS-Scicon  Defence  Limited 


Chapter  1  -  Page  3  of  4 


XD  Ada  MC68040/ARTX  Version  1.2 


INTRODUCTION 


ISO 

LRM 

Operating  System 

Target  Computer 
System 

Validated  Ada  Compiler 

Validated  Ada 
Implementation 

Validation 

Withdrawn  test 
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International  Organization  for  Standardization. 

The  Ada  standard,  or  Language  Reference  Manual,  published  as 
ANSI/MIL-STD-1815A-1983  AND  ISO  8652-1987.  Citations  from  the 
LRM  take  the  form  "<section>.<subsection>:<paragraph>.” 

Software  that  controls  the  execution  of  programs  and  that  provides 
services  such  as  resource  allocation,  scheduling,  input/output  control  and 
data  management.  Usually,  operating  systems  are  predominantly 
software,  but  partial  or  complete  hardware  implementations  are  possible. 

A  computer  system  where  the  executable  form  of  Ada  programs  are 
executed. 

The  compiler  of  a  validated  Ada  implementation. 

An  Ada  implementation  that  has  been  validated  successfully  either  by 
AVF  testing  or  by  registration  (Pro92]. 

The  process  of  checking  the  conformity  of  an  Ada  compiler  to  the  Ada 
programming  language  and  of  issuing  a  certificate  for  this 
implementation. 

A  test  found  to  be  incorrect  and  not  used  in  conformity  testing.  A  test 
may  be  incorrect  because  it  has  an  invalid  test  objective,  fails  to  meet  its 
test  objective,  or  contains  erroneous  or  illegal  use  of  the  Ada 
programming  language. 
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CHAPTER  2 

IMPLEMENTATION  DEPENDENCIES 


2.1  WITHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for  withdrawing  each  test  is 
available  from  either  the  AVO  or  the  AVF.  The  publication  date  for  this  list  of  withdrawn  tests  is  2 
August  1991. 


E28005C 

B28006C 

C32203A 

C34006D 

C35508I 

C35508J 

C35508M 

C35508N 

C35702A 

C35702B 

B41308B 

C43004A 

0451 14A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A 

C46022A 

B49008A 

B49008B 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

C83026A 

B83026B 

C83041A 

B85001L 

C86001F 

C94021A 

C97116A 

C98(X)3B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2.2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  which  are  irrelevant  for  a  given  Ada 
implementation.  Reasons  for  a  test’s  inapplicability  may  be  supported  by  documents  issued  by  the  ISO 
and  the  AJPO  known  as  Ada  Commentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For 
this  implementation,  the  following  tests  were  determined  to  be  inapplicable  for  the  reasons  indicated; 
references  to  Ada  Commentaries  are  included  as  appropriate. 


The  following  159  tests  have  floating-point  type  declarations  requiring  more  digits  than 
SYSTEM.MAX_DIGITS: 


C241130..Y  (11  tests) 
C35706O..Y  (11  tests) 
C35708O..Y  (11  tests) 
C452410..Y  (11  tests) 
C454210..Y  (11  tests) 
C455240..Z  (12  tests) 
C456410..Y  (11  tests) 


C35705O..Y  (11  tests) 
C35707O..Y  (11  tests) 
C35802O..Z  (12  tests) 
C453210..Y  (11  tests) 
C455210..Z  (12  tests) 
C456210..Z  (12  tests) 
C46012O..Z  (12  tests) 
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The  following  20  tests  check  for  the  predefined  type  LONG_INTEGER;  for  this  implementation, 
there  is  no  such  type: 


C35404C 

C45231C 

C45304C 

C45411C 

C45412C 

C45502C 

C45503C 

C45504C 

C45504F 

C45611C 

C45613C 

C45614C 

C45631C 

C45632C 

B52004D 

C55B07A 

B55B09C 

B86001W 

C86006C 

CD7101F 

C35713B.  C45423B,  B86001T  and  C86006H  check  for  the  predefined  type  SHORT_FLOAT;  for  this 
implementation,  there  is  no  such  type. 

C45423A,  C45523A,  and  C45622A  check  that  the  proper  exception  is  raised  if 

MACHINE_OVERFLOWS  is  TRUE  and  the  results  of  various  floating-point  operations  lie  outside 
the  range  of  the  base  type;  for  this  implementation,  MACHlNE_OVERFLOWS  is  FALSE. 

C45531M..P  and  C45532M..P  (8  tests)  check  fixed-point  operations  for  types  that  require  a 
SYSTEM. MAX_MANTISSA  of  47  or  greater;  for  this  implementation.  MAX_MANT1SSA  is  less 
than  47. 

B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than  type  DURATION;  for  this 
implementation,  there  is  no  such  type. 

C96005B  uses  values  of  type  DURATION’S  base  type  that  are  outside  the  range  of  type 
DURATION;  for  this  implementation,  the  ranges  are  the  same. 

CA2009A,  CA2009C..D  (2  tests),  and  CA2009F  instantiate  generic  units  before  their  bodies  are 
compiled;  this  implementation  creates  a  dependence  on  generic  units  as  allowed  by  A1-(X)408  and  Al- 
00506  such  that  the  compilation  of  the  generic  unit  bodies  makes  the  instantiating  units  obsolete. 
(.See  Section  2.3). 

CD1009C  checks  whether  a  length  clause  can  specify  a  non-default  size  for  a  floating-point  type;  this 
implementation  does  not  support  such  sizes. 

CD2A84A,  CD2A84E.  CD2A841..J  (2  tests),  and  CD2A840  use  length  clauses  to  specify  non-default 
sizes  for  access  types;  this  implementation  does  not  support  such  sizes. 

CD2B15B  checks  that  STORAGE_ERROR  is  raised  when  the  storage  size  specified  for  a  collection 
is  too  small  to  hold  a  single  value  of  the  designated  type;  this  implementation  allocates  more  space 
than  was  specified  by  the  length  clause,  as  allowed  by  AI-00558. 
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The  tests  listed  in  the  following  table  check  that  USE_ERROR  is  raised  if  the  given  file  operations 
are  not  supported  for  the  given  combination  of  mode  and  access  method;  this  implementation 
supports  these  operations. 


Test 

File  Operation 

Mode 

File  Access  Method 

CE2102E 

CREATE 

OUT  FILE 

SEQUENTIAL  lO 

CE2102F 

CREATE 

INOUT  FILE  DIRECT  lO 

CE2102J 

CREATE 

OUT  FILE 

DIRECT  lO 

CE2102N 

OPEN 

IN  FILE 

SEQUENTIAL  lO 

CE2102O 

RESET 

IN  FILE 

SEQUENTIAL  lO 

CE2102P 

OPEN 

OUT  RLE 

SEQUENTIAL  lO 

CE2102Q 

RESET 

OUT  FILE 

SEQUENTIAL  lO 

CE2102R 

OPEN 

INOUT  FILE  DIRECT  lO 

CE2102S 

RESET 

INOUT  FILE  DIRECT  lO 

CE2102T 

OPEN 

IN  FILE 

DIRECT  lO 

CE2102U 

RESET 

IN  FILE 

DIRECT  lO 

CE2102V 

OPEN 

OUT  FILE 

DIRECT  lO 

CE2102W 

RESET 

OUT  FILE 

DIRECT  lO 

CE3102F 

RESET 

Any  Mode 

TEXT  lO 

CE3102G 

DELETE 

TEXT  lO 

CE31021 

CREATE 

OUT  FILE 

TEXT  lO 

CE3102J 

OPEN 

IN  FILE 

TEXT  lO 

CE3102K 

OPEN 

OUT  FILE 

TEXT  lO 

The  tests  listed  in  the  following  table  check  the  given  file  operations  for  the  given  combination 

mode  and  access  method;  this  implementation  does  not  support  these  operations. 

Test 

File  Operation 

Mode 

File  Access  Method 

CE2105A 

CREATE 

IN_FILE 

SEQUENTIAL  lO 

CE2105B 

CREATE 

IN  FILE 

DIRECT  lO 

CE3109A 

CREATE 

IN  FILE 

TEXT  lO 

CE2107C..D  (2  tests),  CE2107H,  and  CE2107L  apply  function  NAME  to  temporary  sequential,  direct, 
and  text  files  in  an  attempt  to  associate  multiple  internal  files  with  the  same  external  file; 
USE_ERROR  is  raised  because  temporary  files  have  no  name. 


CE2108B,  CE2108D,  and  CE3112B  use  the  names  of  temporary  sequential,  direct,  and  text  files  that 
were  created  in  other  tests  in  order  to  check  that  the  temporary  files  are  not  accessible  after  the 
completion  of  those  tests;  for  this  implementation,  temporary  files  have  no  name. 


CE2203A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  an  external  sequential  file  is 
exceeded;  this  implementation  cannot  restrict  file  capacity. 

CE2403A  checks  that  WRITE  raises  USE_ERROR  if  the  capacity  of  an  external  direct  file  is 
exceeded;  this  implementation  cannot  restrict  file  capacity. 
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CE3304A  checks  that  SET_LINE_LENGTH  and  SET_PAGE_LENGTH  raise  USE_ERROR  if  they 
specify  an  inappropriate  value  for  the  external  file;  there  are  no  inappropriate  values  for  this 
implementation. 

CE3413B  checks  that  PAGE  raises  LAYOUT_ERROR  when  the  value  of  the  page  number  exceeds 
COUNT’LAST;  for  this  implementation,  the  value  of  COUNT’LAST  is  greater  than  150000,  making 
the  checking  of  this  objective  impractical. 

EE2401D  checks  whether  DIRECT_IO  can  be  instantiated  for  an  element  type  that  is  an 
unconstrained  array  type;  this  implementation  raises  USE_ERROR  on  the  attempt  to  create  a  file, 
because  the  maximum  potential  element  size  exceeds  the  implementation  amit  of  2**16  -  1  bits 

2.3  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  were  required  for  19  tests. 

The  following  test  was  split  into  two  or  more  tests  because  this  implementation  did  not  report  the 
violations  of  the  Ada  Standard  in  the  way  expected  by  the  original  test. 

B97103E 

C45524C..K  (9  tests)  were  graded  passed  by  Test  Modification  as  directed  by  the  AVO.  These  tests 
expect  that  a  repeated  division  will  result  in  zero;  but  the  Ada  standard  only  require.'  that  the  result 
lie  in  the  smallest  safe  interval.  Thus,  the  tests  were  modified  to  check  that  the  result  was  within  the 
smallest  safe  interval,  by  adding  the  following  code  after  line  141;  the  modified  tests  were  passed: 

ELSIF  VAL  <  =  FSAFE_SMALL  THEN  COMMENT  ("UNDERFLOW  SEEMS  GRADUAL"); 

CA2009A,  CA2009C..D  (2  tests),  and  CA2009F  were  graded  inapplicable  by  Evaluation  Modification 
as  directed  by  the  AVO.  These  tests  instantiate  generic  units  before  those  units'  bodies  are  compiled; 
this  implementation  creates  dependencies  as  allowed  by  AI-00408  &  AI-00506  such  that  the 
compilation  of  the  generic  unit  bodies  makes  the  instantiating  units  obsolete,  and  the  objectives  of 
these  tests  cannot  be  met. 

BC3204C,  BC3204D,  BC3205C  and  BC3205D  were  graded  passed  by  Processing  Modification  as 
directed  by  the  AVO.  These  tests  check  that  instantiations  of  generic  units  with  unconstrained  types 
as  generic  actual  parameters  art  illegal  if  the  generic  bodies  contain  uses  of  the  types  that  require 
a  constraint.  However,  the  generic  bodies  are  compiled  after  the  units  that  contain  the  instantiations, 
and  this  implementation  creates  a  dependence  of  the  instantiating  units  on  the  generic  units  as 
allowed  by  AI-00408  and  AI-00506  such  that  the  compilation  of  the  generic  bodies  makes  the 
instantiating  units  obsolete-no  errors  are  detected.  The  processing  of  these  tests  was  modified  by 
re-compiling  the  obsolete  units;  all  intended  errors  were  then  detected  by  the  compiler. 

CE3804H  was  graded  passed  by  Evaluation  Modification  as  directed  by  the  AVO.  This  test  requires 
that  the  string  "-3.525"  can  be  read  from  a  file  using  FLOAT_IO  and  that  an  equality  comparison  with 
the  numeric  literal  ’-3.525’  will  evaluate  to  TRUE;  however,  because  -3.525  is  not  a  model  number, 
this  comparison  may  evaluate  to  FALSE  (LRM  4.9:12).  This  implementation’s  compile-time  and 
run-time  evaluation  algorithms  differ;  thus,  this  check  for  equality  faiL  and  Report. Faned  is  called 
at  line  81,  which  outputs  the  message  "WIDTH  CHARACTERS  NOT  READ."  All  other  checks  were 
passed. 
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CHAPTER  3 

PROCESSING  INFORMATION 


3.1  TESTING  ENVIRONMENT 

The  Ada  implementation  tested  in  this  validation  effort  is  described  by  the  information  given  in  the 
initial  pages  of  this  report  together  with  the  following  additional  details. 

Host  Memory  Size:  37  MBytes 

Communication  Link:  RS232-C 

Bus  system:  VME  BUS 

For  technical  information  about  this  Ada  implementation,  contact: 

Tim  Magness 

EDS-Scicon  Defence  Limited 

Pembroke  House 

Pembroke  Broadway 

Camberley 

Surrey 

GU25  3XD 

For  sales  information  about  this  Ada  implementation,  contact: 

Colin  Foster 

EDS-Scicon  Defence  Limited 

Pembroke  House 

Pembroke  Broadway 

Camberley 

Surrey 

GU25  3XD 

Testing  of  this  Ada  implementation  was  conducted  at  the  customer’s  site  by  a  validation  team  from 
the  AVF. 

3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes  each  test  of  the  customized  test 
suite  in  accordance  with  the  Ada  Programming  Language  Standard,  whether  the  test  is  applicable  or 
inapplicable;  otherwise,  the  Ada  Implementation  fails  the  ACVC  [Pro92]. 

For  all  processed  tests  (inapplicable  and  applicable),  a  result  was  obtained  that  conforms  to  the  Ada 
Programming  Language  Standard. 
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The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various  categories.  All  tests  were 
processed,  except  those  that  were  withdrawn  because  of  test  errors  (item  b;  see  section  2.1),  those 
that  require  a  floating-point  precision  that  exceeds  the  implementation’s  maximum  precision  (item 
e;  see  section  2.2),  and  those  that  depend  on  the  support  of  a  file  system  --  if  none  is  supported  (item 
d).  All  tests  passed,  except  those  that  are  listed  in  sections  2.1  and  2.2  (counted  in  items  b  and  f. 
below). 


a)  Total  Number  of  Applicable  Tests  3835 

b)  Total  Number  of  Withdrawn  Tests  95 

c)  Processed  Inapplicable  Tests  240 

d)  Non-Processed  I/O  Tests  0 

e)  Non-Processed  Floating-Point  Precision  Tests  0 

0  Total  Number  of  Inapplicable  Tests  240  (c-t-d-f-c) 

g)  Total  Number  of  Tests  for  ACVC  1.11  4170  (a-l-b-t-f) 


3.3  TEST  EXECUTION 

A  magnetic  tape  containing  the  customized  te.st  suite  (see  section  1.3)  war.  taken  on-site  by  the 
validation  team  for  processing. 

The  contents  of  he  magnetic  tape  were  loaded  onto  a  VAX  4000-.300  and  then  transferred  via 
DECnct  to  the  host  computer. 

After  the  test  files  were  loaded  onto  the  host  computer,  the  full  set  of  tests  was  processed  by  the  Ada 
implementation. 

The  tests  were  compiled  and  linked  on  the  host  computer  system,  as  appropriate.  The  executable 
images  were  transferred  to  the  target  computer  sy'Stem  by  the  communications  link  described  above, 
and  run.  The  results  were  captured  on  the  host  computer  system. 

Testing  was  performed  using  command  scripts  provided  by  the  customer  and  reviewed  by  the 
validation  team.  See  Appendix  B  for  a  complete  listing  of  the  processing  options  for  this 
implementation.  It  also  indicates  the  default  options.  The  options  invoked  explicitly  for  validation 
testing  during  this  test  were: 

/LIST  Used  for  tests  for  which  compilation  listings 

are  required 

/DEV=DAT_0  )  In  house  compiler  options  to  remove 

)  extraneous  listing 

&  SD-OPT=  (SUPPRESS_DIFFERENCES)  )  information  (eg  dates  and  headers) 

Test  output,  compiler  and  linker  listings,  and  job  logs  were  captured  on  magnetic  tape  and  archived 
at  the  AVF.  The  listings  examined  on-site  by  the  validation  team  were  also  archived. 
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APPENDIX  A 
MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing  the  ACVC.  The  meaning  and 
purpose  of  these  parameters  are  explained  in  (UG89].  The  parameter  values  are  presented  in  two 
tables.  The  first  table  lists  the  values  that  are  defined  in  terms  of  the  maximum  input-line  length, 
which  is  the  value  for  $MAX_IN_LEN"also  listed  here.  These  values  are  expressed  here  as  Ada 
string  aggregates,  where  "V"  represents  the  maximum  input-line  length. 

Macro  Parameter  Macro  Value 


$MAX_IN_LEN 

$BIG_ID1 

$BIG_ID2 

$BIG_ID3 

$BIG_ID4 

$BIG_INT_LIT 

$BIG_REAL_LIT 

$BIG_STRING1 

$BIG_STRING2 

SBLANKS 

$MAX_LEN_INT_BASED_LITERAL 


255 

(1..V-1  =>  ’A’,  V  =>  ’!’) 

(1..V-1  =>  ’A’,  V  =>  ’2’) 

(1..V/2  =>  ’A’)  &  ’3’  &  (1..V-1-V/2  =>  ’A’) 
(1..V/2  =>  ’A’)  &  ’4’  &  (1..V-1-V/2  =>  ’A’) 
(1..V-3  =>  ’O’)  &  "298" 

(1..V-5  =>  ’O’)  &  "690.0" 

’"’  &  (1..V/2  =>  ’A’)  &  ’"’ 

’"’  &  (1..V-1-V/2  =>  ’A’)  &  ’1’  &  ’"’ 

(1..V-20  =>  ”) 


"2;"  &  (1..V-5  =>  ’O’)  &  "11." 


$MAX_LEN_REAL  BASED_LITERAL 

"16:"  &  (1..V-7  =>  ’O’)  &  "F.E:" 

$MAX_STRING_LITERAL  ’"’  &  (1..V-2  =>  ’A’)  &  ’"’ 


Validation  Summary  Report 


AVF_VSR_90S02/8.A 


EDS-Scicon  Defence  Limited 


Apperidix  A  -  Page  1  of  A 


XD  Ada  MC68040/ARTX  Version  1.2 


MACRO  PARAMETERS 


The  following  table  lists  all  of  the  other  macro  parameters  and  their  respective  values. 

Macro  Parameter 

Macro  Value 

$ACC_SIZE 

32 

$ALIGNMENT 

1 

$COUNT_LAST 

2147483647 

$DEFAULT_MEM_SIZE 

2147483647 

$DEFAULT_STOR_UNIT 

8 

$DEFAULT_SYS_NAME 

MC68040 

$DELTA_DOC 

2#1.0#E-31 

$ENTRY_ADDRESS 

SYSTEM.TO_ADDRESS(16#68#) 

$ENTRY_ADDRESS1 

SYSTEM.TO_ADDRESS(16#6C#) 

$ENTRY_ADDRESS2 

SYSTEM.TO_ADDRESS(16#70#) 

$FIELD_LAST 

255 

$FILE_TERMINATOR 

ASCII.CR  &  ASCII.FF  &  ASCII.SUB 

$FIXED_NAME 

NO_SUCH_TYPE 

$FLOAT_NAME 

LONG_LONG_FLOAT 

$FORM_STRING 

ftff 

$FORM_STRING2 

"CANNOT_RESTRICT_FlLE_CAPACITY" 

$GREATER_THAN_DURATION 

131072.0 

$GREATER_THAN_DURATION. 

BASE  LAST 

131073.0 

SGREATER  THAN  FLOAT  BASE  LAST 

3.40283E+38 

$GREATER_THAN  FLOAT  SAFE  LARGE 

4.25354E+37 

$GREATER_THAN  SHORT  FLOAT  SAFE  LARGE 

"NO_SUCH_TYPE" 
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$HIGH_PRIORITY  15 

$ILLEGAL_EXTERNAL_FILE_NAME1 

ILLEGAL:  FILE_NAME1 

$ILLEGAL_EXTERNAL_FILE  NAME2 

ILLEGAL:  FILE_NAME2 

$INAPPROPRIATE_LINE_LENGTH  -1 

$INAPPROPRIATE_PAGE_LENGTH 


$INCLUDE_PRAGMA1 

$INCLUDE_PRAGMA2 

$INTEGER_nRST 

$INTEGER_LAST 

$INTEGER_LAST_PLUS_1 

$INTERFACE_LANGUAGE 

$LESS_THAN_DURATION 

$LESS_THAN_DURATION_BASE 

$LINE_TERMINATOR 

$LOW_PRIORITY 

$MACHINE_CODE_STATEMENT 

$MACHINE_CODE_TYPE 

$MANTISSA_DOC 

$MAX_DIGn'S 

$MAX_INT 

$MAX_INT_PLUS_1 

$MIN_INT 

SNAME 

$NAME_LIST 


-1 

PRAGMA  INCLUDE  ("A28006D1.TST') 

PRAGMA  INCLUDE  ("B28006D1.TST") 

-2147483648 

2147483647 

2147483648 

ASSEMBLER 

-131072.0 

FIRST 

-131073.0 

ASCII.CR 

0 

OPERANDLESS_INST‘ (OPCODE  =  >NOP); 
OPERANDLESS_INST 
31 
18 

2147483647 

2147483648 

-2147483648 

SHORT_SHORTJNTEGER 

MC68040 
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$NAME_SPECIFICATION  1 

$NAME_SPECIFICATION2 

$NAME_SPECIFICATION3 

$NEG_BASED_INT 

$NEW_MEM_SIZE 

$NEW_STOR_UNIT 

$NEW_SYS_NAME 

$PAGE_TERMINATOR 

$RECORD_DEnNITION 

$RECORD_NAME 

$TASK_SIZE 

$TASK_STORAGE_SIZE 

STICK 

$VARIABLE_ADDRESS 
$VAR1ABLE_ADDRESS  1 
$VARIABLE_ADDRESS2 
$YOUR_PRAGMA 


X2120A 

X2120B 

X3119A 

16#FFFF_FFFF# 

123456 

8 

MC68040 

ASCII.CR  &  ASCII.FF 

RECORD  OPCODE:  OPERANDLESS_OP;END 
RECORD; 

OPERANDLESS_INST 

32 

2048 

162.5E-6 

SYSTEM.TO_ADDRESS(16#40C#) 

SYSTEM.TO_ADDRESS(16#408#) 

SYSTEM.TO_ADDRESS(16#404#) 

EXPORT_OBJECT 
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APPENDIX  B 

COMPILATION  SYSTEM  OPTIONS 


The  compiler  options  of  this  implementation,  as  described  in  this  Appendix,  are  provided  by  the 
customer.  Unless  specifically  noted  otherwise,  references  in  this  appendix  are  to  compiler 
documentation  and  not  this  report. 
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XDADA 


XDADA 

Invokes  the  XD  Ada  compiler  to  compile 

one  or  more  source  files. 

Format 

XDADA  file-spec[,...] 

Command  Qualifiers 

Defaults 

/LIBRARY  =  directory-spec 

/LIBRARY  =  XDADA$LIB 

Positional  Qualifiers 

Defaults 

/(N01ANALYSIS_DATA[  =  file-spec] 

/NOANALYSIS.DATA 

/(NOjCHECK 

See  text. 

/[NOjCOPY.SOURCE 

/COPY_SOURCE 

/INOjDEBUG]-  (option(....D| 

/DEBUG.  ALL 

/(NOjDIAGNOSTICSl  -  file-spec) 

/NODIAGNOSTICS 

/lNO]ERROR_LIMIT|  =  n| 

/ERROR_LIMIT  =  30 

/(NO)  LIST]  .file-spec) 

/NOLIST 

/(NO)LOAD(  =  option) 

/LOAD  .REPLACE 

/(NO)MACHINE_CODE(  =  option) 

/NOMACHINE.CODE 

/lNO)NOTE_SOURCE 

/NOTE.SOURCE 

/(NO)OPTIMIZE( .  option) 

See  text. 

/(NO)PREDEFINED_UNIT 

/NOPREDEFINED.UNIT 

/1N0)SH0W(  =  option) 

/SHOW.  PORTABILITY 

/(NO)SYNTAX_ONLY 

/NOSYNTAX.ONLY 

/INOIWARNINGS).  (option),...])) 

See  text. 

Prompt 

.File: 

Command  Parameters 


file-spec 

Specifies  one  or  more  XD  Ada  source  files  to  be  compiled.  If  you  do 
not  specify  a  file  type,  the  compiler  uses  the  default  file  type  of  .ADA. 
No  v>^dcard  characters  are  allowed  in  the  file  specifications. 
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XDADA 


If  you  specify  several  source  files  as  arguments  to  the  XDADA  com¬ 
mand,  you  must  separate  adjacent  file  specifications  with  a  comma  ( , ). 
If  you  specify  more  than  one  input  file,  you  must  separate  adjacent  file 
specifications  with  a  comma  {, ).  You  cannot  use  a  plus  sign  ( -t- )  to 
separate  file  specifications. 


Description 

The  XDADA  command  is  one  of  four  commands  used  to  compile  com¬ 
pilation  uiuts.  The  other  three  are  the  XDACS  COMPILE,  RECOMPILE 
and  LOAD  commands. 

The  XDADA  command  can  be  used  at  any  time  to  compile  one  or 
more  source  files  (.ADA).  Source  files  are  compiled  in  the  order  they 
appear  on  the  commemd  line.  If  a  source  file  contauns  more  than  one 
compilation  unit,  they  are  compiled  in  the  order  they  appear  in  the 
source  file. 

The  XDADA  command  compiles  units  in  the  context  of  the  current 
program  library.  Whenever  a  compilation  unit  is  compiled  without 
error,  the  current  program  library  is  updated  with  the  object  module 
and  other  products  of  the  compilation. 


Command  Qualifiers 

l  LIBRARY = directory-spec 

Specifies  the  program  library  that  is  to  be  the  current  program  library 
for  the  duration  of  the  compilation.  The  directory  specified  must  be  an 
already  existing  XD  Ada  program  library.  No  wildcard  characters  are 
allowed  in  the  directory  specification. 

By  default,  the  current  program  library  is  the  program  library  last 
specified  in  an  XDACS  SET  LIBRARY  command.  The  logical  name 
XDADASUB  is  assigned  to  the  program  library  specified  in  an  XDCAS 
SET  LIBRARY  conunand. 


Positional  Qualifiers 

IANALYSIS_DATA[  =  flle-spec] 

INOANALYSIS.DATA  (D) 

Controls  whether  a  data  analysis  file  containing  source  code  cross- 
reference  and  static  analysis  information  is  created.  The  data  analysis 


XDADA  Command  Definition  B-3 


XDADA 


file  is  supported  only  for  use  with  DIGITAL  layered  products,  such  as 
the  VAX  Source  Code  Analyzer. 

One  data  analysis  file  is  created  for  each  source  file  compiled.  The 
default  directory  for  data  analysis  files  is  the  cunent  default  directory. 
The  default  file  n^lme  is  the  ntime  of  the  source  file  being  compiled. 

The  default  file  type  is  .ANA.  No  wildcard  characters  are  allowed  in  the 
file  specification. 

By  default,  no  data  analysis  file  is  created. 

fCHECK 

INOCHECK 

Controls  whether  all  run-time  checks  are  suppressed.  The  /NOCHECK 
qualifier  is  equivalent  to  having  all  possible  SUPPRESS  pragmas  in  the 
source  code. 

Explicit  use  of  the  /CHECK  qualifier  overrides  any  occurrences  of  the 
pragmas  SUPPRESS  and  SUPPRESS_ALL  in  the  source  code,  without 
the  need  to  edit  the  source  code. 

By  default,  run-time  checks  are  suppressed  only  in  cases  where  a 
pragma  SUPPRESS  or  SUPPRESS_ALL  appears  in  the  source. 

See  the  Reference  Manual  for  the  Ada  Programming  Language  for  more 
information  on  the  pragmas  SUPPRESS  and  SWPRESS.ALL. 

/COPY_SOURCE  (D) 

inoc6py_source 

Controls  whether  a  copied  source  file  (.ADC)  is  created  in  the  current 
program  library  when  a  compilation  unit  is  compiled  without  error.  The 
RECOMPILE  command  (and  thus  the  COMPILE  command)  requires 
that  a  copied  source  file  exist  in  the  current  program  library  for  any  unit 
that  is  to  be  recompiled. 

By  default,  a  copied  source  file  is  created  in  the  current  program  library 
when  a  unit  is  compiled  without  error. 

fDEBUG[=i(optlon[....])J  (D) 

INODEBUG 

Controls  which  compiler  debugging  options  are  provided.  You  can 
debug  XD  Ada  programs  with  the  XD  Ada  Debugger.  You  can  request 
the  following  options: 
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ALL 

NONE 

INOISYMBOLS 

[NOITRACEBACK 


Provides  both  SYMBOLS  and  TRACEBACK. 

Provides  neither  SYMBOLS  nor  TRACEBACK. 

Controls  whether  debugger  symbol  records  are  in¬ 
cluded  in  the  object  file. 

Controls  whether  traceback  information  (a  subset  of 
the  debugger  symbol  information)  is  included  in  the 
object  file. 


By  default,  both  debugger  symbol  records  and  traceback  information  are 
included  in  the  object  file  (/DEBUG- ALL,  or  equivalently:  /DEBUG). 

/DIAGNOSTICS! = file-spec] 

INODIAGNOSTICS  (D) 

Controls  whether  a  diagnostics  file  containing  compiler  messages  and 
diagnostic  information  is  created.  The  diagnostics  file  is  supported  only 
for  use  with  DIGITAL  layered  products,  such  as  the  VAX  lUinguage- 
Sensitive  Editor. 

One  diagnostics  file  is  created  for  each  source  file  compiled.  The 
default  directory  for  diagnostics  files  is  the  current  default  directory. 

The  default  file  name  is  the  name  of  the  source  file  being  compiled. 
The  default  file  type  is  DIA.  No  wildcard  characters  are  allowed  in  the 
file  specification. 

By  default,  no  diagnostics  file  is  created. 

/ERROR_UMIT[z:n] 

INOERROR_LIMIT 

Controls  whether  execution  of  the  XDADA  command  for  a  given 
compilation  unit  is  terminated  upon  the  occurrence  of  the  nth  E-level 
error  within  that  unit. 

Error  counts  are  not  accumulated  across  a  sequence  of  compilation 
units.  If  the  /ERROR.UMIT  -  n  option  is  specified,  each  compilation 
unit  may  have  up  to  n-1  errors  without  terminating  the  compilation. 
When  the  error  limit  is  reached  within  a  compilation  unit,  compilation  of 
that  unit  is  terminated,  but  compilation  of  subsequent  units  continues. 

The  /ERROR_ LIMIT  -  0  option  is  equivalent  to  ERROR.LIMIT  - 1 . 

By  default,  execution  of  the  XDADA  command  is  terminated  for  a  given 
compilation  unit  upon  the  occurrence  of  the  30th  E-level  error  w-ithin 
that  unit  (equivalent  to  /ERROR_LIMIT-30). 
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I  UST[= file-spec] 

/NOUST  (D) 

Controls  whether  a  listing  file  is  created.  One  listing  file  is  created 
for  each  source  file  compiled.  The  default  directory  for  listing  files  is 
the  current  default  directory.  The  default  file  name  is  the  name  of  the 
source  file  being  compiled.  The  default  file  type  is  .US.  No  wildcard 
characters  are  allowed  in  the  file  specification. 

By  default,  the  XDADA  command  does  not  create  a  listing  file. 

/LOAD]  =  option]  (D) 

INOLOAD 

Controls  whether  the  cvirrent  program  library  is  updated  with  the 
successfully  processed  units  contained  in  the  specified  source  files. 
Depending  on  other  qualifiers  specified  (or  not  specified)  with  the 
XDADA  command,  processing  can  involve  full  compilation,  syntax 
checking  only,  and  so  on.  The  /NOLOAD  qualifier  causes  the  units 
in  the  specified  source  files  to  be  processed,  but  prevents  the  current 
program  library  from  being  updated. 

You  can  specify  the  following  option: 

[NO]REPLACE  Controls  whether  a  unit  added  to  the  current 

program  library  replaces  an  existing  unit  with  the 
same  name.  If  you  specify  the  NOREPLACE  option, 
the  unit  is  added  to  the  current  program  library  oidy 
if  no  existing  uiut  has  the  same  name,  except  if  the 
new  unit  is  the  corresponding  body  of  an  existing 
specification  or  vice  versa. 

By  default,  the  current  prograun  library  is  updated  with  the  success¬ 
fully  processed  units,  and  a  unit  added  to  the  ciuxent  program  library 
replaces  an  existing  unit  with  the  same  name. 

/MACHINE  CODE] = option] 

/NOMACHINE_CODE  (D) 

Controls  whether  generated  machine  code  (approximating  assembly 
language  notation)  is  included  in  the  listing  file. 

You  can  specify  one  of  the  following  options: 
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SYMBOLlC;NONE  Provides  machine  code  listing  with  no  annotation. 

bYMBOLlC;NORMAL  Provides  machine  code  in  the  listing  file:  where 

possible,  instructions  are  annotated  with  simple  Ada 
names. 

SYMBOUCiMAXIMAL  Provides  machine  code  in  the  listing  file:  where 

possible,  instructions  are  annotated  with  Ada  names, 
in  expanded  form  if  necessary. 

The  /MACHINE_CODE  qualifier  without  options  is  equivalent  to 
/MACHINE.CODE  -  SYMBOLIC:NORMAL. 

INOTE_SOURCE  (D) 

INONOTE_SOURCE 

Controls  whether  the  file  specification  of  the  source  file  is  noted  in  the 
program  library  when  a  unit  is  compiled  without  error.  The  COMPILE 
command  uses  this  information  to  locate  revised  source  files. 

By  default,  the  file  specification  of  the  source  file  is  noted  in  the  pro¬ 
gram  library  when  a  unit  is  compiled  without  error. 

IOPTIMIZE[  =  (optlon[,  .  .  .  ]) 

/NOOPTIMIZE 

Controls  the  level  of  optimization  that  is  applied  in  producing  the 
compiled  code.  You  can  specify  one  of  the  following  primary  options; 

Provides  full  optimization  with  time  as  the  primary 
optimization  criterion.  Overrides  any  occurrences  of 
the  pragma  OPTIMIZE(SPACE)  in  the  source  rode. 

Provides  full  optinuzation  with  space  as  the  primary 
optimization  criterion.  Overrides  any  occurrences  of 
the  pragma  OPTIMIZE(TIME)  in  the  source  code. 

Suggested  when  active  development  of  a  program 
is  in  progress.  Provides  some  optimization,  but 
development  considerations  and  ease  of  debugging 
take  preference  over  optimization.  This  option 
overrides  pragmas  that  establish  a  dependence  on  a 
subprogram  ithe  pragma  INLINE),  and  thus  reduces 
the  need  for  recompilations  when  such  bodies  are 
modified. 

NONE  Provides  no  optimization.  Suppresses  expansions  in 

line  of  subprograms,  including  those  specified  by  the 
pragma  INLINE. 

The  /NOOPTIMIZE  qualifier  is  equivalent  to  /OPTIMIZE  »  NONE. 


TIME 

SPACE 

DEVELOPMENT 
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By  default,  the  XDADA  command  applies  full  optimization  unth  time 
as  the  primary  optimization  criterion  (like  /OPTIMIZE -TIME,  but 
observing  uses  of  the  pragma  OPTIMIZE). 

The  /OPTIMIZE  qualifier  also  has  a  set  of  secondary  options  that  you 
can  use  separately  or  together  with  the  primary  option?  to  override  the 
default  behavior  for  inline  expansion  and  code  motion. 

The  INLINE  secondary  option  can  have  the  following  values; 

INUNEiNONE  Disables  subprogram  expansion  in  line.  This  option 

overrides  any  occurrences  of  the  pragma  INLINE 
in  the  source  code,  without  having  to  edit  the 
source  file.  It  also  disables  implicit  expansion  in 
line  of  subprograms.  {Implicit  expansion  in  line  means 
that  the  compiler  assumes  a  pragma  INLINE  for 
certain  subprograms  as  an  optimization.)  A  call  to  a 
Subprogram  in  another  unit  is  not  expanded  in  line, 
regardless  of  the  /OPTIMIZE  options  in  effect  when 
that  unit  was  compiled. 

INUNEiNORMAL  Provides  normal  subprogram  expansion  in  line. 

Subprograms  to  which  an  explicit  pragma  INLINE 
applies  are  expanded  in  line  under  certain  condi¬ 
tions.  In  addition,  some  subprograms  are  implicitly 
expanded  in  line.  The  compiler  assumes  a  pragma 
INLINE  for  calls  to  some  small  local  subprograms 
(subprograms  that  are  declared  in  the  same  unit  as 
the  unit  in  which  the  call  occurs). 

INLINE:SUBPROGRAMS  Provides  maximal  subprogram  expansion  in  line.  In 

addition  to  the  normjil  subprogram  expansion  in 
line  that  occurs  when  INUNErNORMAL  is  specified, 
this  option  results  in  implicit  expansion  in  line  of 
some  small  subprograms  declared  in  other  units. 

The  compiler  assumes  a  pragma  INLINE  for  any 
subprogram  if  it  improves  execution  speed  and 
reduces  code  size.  This  option  may  establish  a 
dependence  on  the  body  of  another  unit,  as  would  be 
the  case  if  a  pragma  INLINE  were  specified  explicitly 
in  the  source  code. 
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INUNE;MAXIMAL  Provides  maximal  subprogram  expansion  in  line. 

Maximal  subprogram  expansion  in  line  occurs  as  for 
INUNE;SUBPROGRAMS. 

INUNEiGENERlCS  Provides  normal  subprogram  inline  expansion  and 

maximal  generic  inline  expansion.  With  this  option, 
subprogram  inline  expansion  occurs  in  the  same 
manner  as  for  INUNE:NORMAL.  The  compiler 
assumes  a  pragma  INUNE.CENERIC  for  everv 
instantiation  in  the  unit  being  compiled  unless 
a  generic  body  is  not  available.  This  option  may 
establish  a  dependence  on  the  body  of  another  unit, 
as  would  be  the  case  if  a  pragma  INUNE.GENERIC 
were  specified  explicitly  in  the  source  code. 

The  MOTION  secondary  option  can  have  the  following  values: 
MOTION;NONE  Disables  code  motion  optimizations. 

MOTION:LOOPS  Permits  code  motion  optimization  of  loops.  Where 

the  compiler  detects  that  a  loop  body  contains 
invariant  processing,  it  may  generate  code  in  which 
this  processing  is  performed  before  entry  to  the  loop 
instead  of  within  the  loop. 

MOTION; MAXIMAL  Permits  all  code  motion  optimizations.  In  addition 

to  the  optirruzation  of  loops  that  occurs  when 
MOTlONiLOOPS  is  specified,  this  option  permits 
analogous  optimization  of  if  and  case  statements: 
where  the  compiler  detects  that  the  branches  of  an  if 
or  case  statement  contain  common  processing,  it  may 
j^enerate  code  in  which  this  processing  is  performed 
before  evaluation  of  the  corresponding  condition  or 
case  expression  instead  of  within  the  branches. 

By  default,  the  /OPTIMIZE  qualifier  primary  options  have  the  following 
secondary-option  values: 

/OPTIMIZE  =  TIME  -UNUNE:NORMAL,MOTION:LOOPS) 

/  OPTIMIZE  =  SPACE  -(INUNE:N0RMAL,M0T10N;MAXIMAL) 

/OPTIMIZE  =  DEVELOPMENT  =(INUNE:NONE,MOTION:NONE) 

/OPTIMIZE  =  NONE  =(INUNE:NONE,MOTION:NONE) 

/PREDEFINED_UNIT 
INOPREDEFINEDJJNIT  (D) 

Controls  the  compilation  of  package  SRUN_TIME_SYSTEM,  pack¬ 
age  $TASKING_SYSTEM,  and  package  MACHINE_CODE.  You  must 
jpecify  this  qucilifier  in  order  to  be  able  to  compile  these  packages. 
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The  qualifier  is  not  required  for  the  compilation  of  any  other  source 

files.  See  the  XD  Ada  MC68020  Run-Time  Reference  Manual  for  more 

information. 

By  default,  /PREDEFINED_UNIT  is  omitted. 

/SHOWl  =  option]  (D) 

/NOSHOW 

Controls  the  listing  file  options  included  when  a  listing  file  is  provided. 

You  can  specify  one  of  the  follovnng  options: 

ALL  Provides  all  listing  file  options. 

[NOIPORTABILITY  Controls  whether  a  program  portability  summary 

is  included  in  the  listing  file.  By  defaiilt,  the 
XDADA  command  provides  a  portability  sum¬ 
mary  (ISHOW- PORTABILITY).  See  Afjpendix  E 
for  details  of  what  can  be  included  in  a  porta¬ 
bility  summary.  See  Chapter  5  of  Version  2.0  of 
Developing  Ada  Programs  on  VMS  Systems  for  more 
information  on  program  portability. 

NONE  Provides  none  of  the  listing  file  options  (same  as 

/NOSHOW). 


By  default,  the  XDADA  command  provides  a  portability  summary 
(/SHOW  -  PORTABIUTY). 

/SYNTAXJONLY 
/NOSYNfAX_ONLY  (D) 

Controls  whether  the  source  file  is  to  be  checked  only  for  correct  syntax. 
If  you  specify  the  /SYNTAX.ONLY  qualifier,  other  compiler  checks  are 
not  performed  (for  example,  semantic  analysis,  type  checking,  and  so 
on). 

By  default,  the  compiler  performs  all  checks. 

/WARNINGS] = (message-option],...])] 

INOWARNINGS 

Controls  which  categories  of  mformational  (I-level)  and  warning  (W- 
level)  messages  are  displayed  and  where  those  messages  are  displayed. 
You  can  specify  any  combination  of  the  following  message  options: 

WARNINGS:  (desfinafion[,...l) 

NOWARNINGS 

WEAK_WARNINGS:  (desfi nation [,...]) 
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NOWEAK.WARNINGS 

SUPPLEMENTAL;  (destination[,...]) 
NOSUPPLEMENTAL 

COMPILATION  NOTES:  {destimtion[, . . .]) 
NOCOMPILATION.NOTES 

STATUS:  (destinationl,...]) 

NOSTATUS 


The  possible  values  of  destination  are  ALL,  NONE,  or  any  combination 
of  TERMINAL  (terminal  device),  LISTING  (Usting  file),  DIAGNOSTICS 
(diagnostics  file).  The  message  categories  are  summarized  as  follows: 


WARNINGS 

WEAK.WARNINGS 


SUPPLEMENTAL 

COMPILATION.NOTES 


STATUS 


W-level:  Indicates  a  definite  problem  in  a  legal 
program,  for  example,  an  unknown  pragma. 

I-level:  Indicates  a  potential  problem  in 
a  legal  program;  for  example,  a  possible 
CONSTRaInT.ERROR  at  run  time.  These 
are  the  only  kind  of  1-level  messages  that  are 
counted  in  the  summary  statistics  at  the  end  of 
a  compilation. 

1-level:  Additional  information  associated  with 
preceding  E-level  or  W-level  diagnostics. 

1-level:  Information  about  how  the  compiler 
translated  a  program,  such  as  record  layout, 
parameter-passing  mechanisms,  or  decisions 
made  for  the  pragmas  INLINE,  INTERFACE,  or 
the  import-subprogram  pragmas. 

I-level:  End  of  compilation  statistics  and  other 
messages. 


The  defaults  are  as  follows. 

/WARN I NGS- ( WARN : ALL , WEAK : ALL , SUPP : ALL , COMP : NONE , STAT : LI ST ) 

Note  that  abbreviations  are  valid. 

If  you  specify  only  some  of  the  message  categories  with  the 
/WARNINGS  qualifier,  the  default  values  for  other  categories  are  used. 


XDADA  Command  Definition  B-1 1 


XDADA 


Examples 

S  XDADA  model_:mterface_,model_interface,control_loop 

The  XDADA  command  compiles  the  compilation  units  con¬ 
tained  in  the  three  files  MODEL_INTERFACE_.ADA,  MODEL_ 
INTERFACE.ADA,  and  CONTROL. LOOP.ADA,  in  the  order  given. 

2.  s  xdada/list/show-all  screen_io_,screen_io 

The  XDADA  conrunand  compiles  the  compilation  units  contained 
in  the  two  files  SCREEN.IO.  ADA  and  SCREEN.IO.ADA,  in  the 
order  given.  The  /LIST  qualifier  creates  the  listing  files  SCREEN. 
IO..LIS  and  SCREEN.IO.LIS  in  the  current  default  directory.  The 
/SHOW  -  ALL  qualifier  causes  all  listing  file  options  to  be  provided 
in  the  listing  files. 
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LINKER  OPTIONS 

The  linker  options  of  this  Ada  implementation,  as  described  in  this  Appendix,  are  provided  by  the 
customer.  Unless  specifically  noted  otherwise,  references  in  this  appendix  are  to  linker  documentation 
and  not  to  this  icport. 


Validation  Summary  Report 


AVT_VSR_90502/8.t 


EDS-Scicon  Defence  Limited 
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Creates  an  executable  image  file  for  the  specified  units. 


Format 


LINK  unit-name  [file-spec[, . . .]] 
LINK/NOMAIN  unit-name[,...]  file-specf,...] 


Command  Qualifiers 
/AFTER  =  time 
/BATCH_LOG  =  file-spec 
/BRIEF 

/COMMAND! « file-spec] 
/(NOjDEBUG 

/ELABORATION  =  file-spec 
/FULL 

/[NO]  I  MAG  E( » file-spec] 
/(NO]KEEP 
/[NO]LOG 
/|NO]MAIN 

/{NOJMAP!  =  file-spec] 

/NAME*  job-name 

/[NO]NOTIFY 

/OUTPUT*  file-spec 

/(NO]PRINTER(  =  queue-name] 

/QUEUE  *  queue-name 

/|NO]SELECTIVE 

/SUBMIT 

/WAIT 

Parameter  Qualifiers 

/LIBRARY 

/MAPPING 

/TARGET 


Defaults 

/AFTER*  TODAY 
See  text. 

See  text. 

See  text. 

/NODEBUG 
See  text. 

See  text. 

/IMAGE 

/KEEP 

/NOLOG 

/MAIN 

/NOMAP 

See  text. 

/NOTIFY 

/OUTPUT  *  SYS$OUTPUT 

/NOPRINTER 

/QUEUE  *SYS$BATCH 

/SELECTIVE 

/WAIT 

/WAIT 

Defaults 
See  text. 

See  text. 

See  text. 
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Prompts 

Unit: 

.File: 


Command  Parameters 

unit-name 

By  default  (or  if  you  specify  the  /MAIN  qualifier): 

•  You  can  specify  only  one  unit,  the  source  code  of  which  must  be 
written  in  XD  Ada. 

•  The  parameter  unit-name  specifies  the  XD  Ada  main  program,  which 
must  be  a  procedure  or  function  with  no  parameters.  If  the  main 
program  is  a  function,  it  must  return  a  value  of  a  discrete  type;  the 
function  value  is  used  as  the  VMS  image  exit  value. 

If  you  specify  the  /NOMAIN  qualifier: 

•  You  can  specify  one  or  more  foreign  units  that  are  to  be  included 
in  the  executable  image.  The  unit  irames  may  include  percent  signs 
( % )  and  asterisks  ( * )  as  wildcard  characters.  (See  the  VMS  DCL 
Concepts  Manual  for  detailed  information  on  wildcard  characters.) 

•  The  image  transfer  address  comes  from  one  of  the  foreign  files 
specified. 

flle-sfjec 

Specifies  a  list  of  object  files,  object  libraries,  mapping  definition  files, 
and  target  definition  files,  that  are  to  be  used  in  lining  the  program. 
The  default  directory  is  the  current  default  directory.  TTie  default  file 
type  is  .XOB,  unless  the  /LIBRARY,  /MAPPING,  or  /TARGET  qualifier  is 
used.  No  wildcard  characters  are  allowed  in  a  file  specification. 

If  the  file  is  an  object  library,  you  must  use  the  /LIBRARY  qualifier.  The 
default  file  type  is  .XLB. 

If  the  file  is  a  mapping  definition  file,  you  must  use  the  /MAPPING 
qualifier.  The  default  file  type  is  .MPD. 

If  the  file  is  a  target  definition  file  you  must  use  the  /TARGET  qualifier. 
The  default  file  type  is  .TGD. 

If  you  specify  the  /NOMAIN  qualifier,  the  image  transfer  address  comes 
from  one  of  the  files  (not  units)  specified. 
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Description 

The  LINK  command  performs  the  following  steps; 

1.  Runs  the  prebuild  phase  to  generate  an  elaboration  list. 

2.  Checks  if  a  pragma  LINK_OPTION  is  specified  for  the  main  pro¬ 
gram,  and  if  specified,  verifies  that  the  designated  link  option  name 
is  available  in  the  current  program  library.  If  available,  the  copied 
link  option  files  in  the  library  corresponding  to  the  link  option  are 
used,  unless  overridden  by  the  /TARGET  or  /MAPPING  qualifiers. 

Note  that,  unlike  the  CHECK  command,  the  pragma  LINK_ 
OPTION  association  for  units  other  than  the  main  program  unit 
is  not  checked. 

If  no  target  link  option  is  given  for  the  main  program  unit  or  the 
designated  target  link  option  is  not  found  in  the  library,  and  the 
logical  name  XDADA$TARGET_DEF  is  not  defined,  and  a  /TARGET 
qualifier  is  not  specified  on  the  LINK  command  line,  an  error  is 
issued.  If  no  mapping  link  option  is  given  for  the  main  program  unit 
or  the  designated  mapping  link  option  is  nc»  found  in  the  library, 
and  the  logical  name  XDADA$MAPPING_DEF  is  not  defined,  and  a 
/MAPPING  qualifier  is  not  specified  on  the  XDACS  LINK  command 
line,  the  default  mapping  in  the  target  definition  file  is  used, 

3.  If  LINK/NOMAIN  is  not  specified,  checks  that  only  one  unit  is 
specified  and  that  it  is  an  XD  Ada  main  program. 

4.  Forms  the  closure  of  the  main  program  (LINK/MAIN)  or  of  the 
specified  units  (LINK/NOMAIN)  and  verifies  that  all  units  in  the 
closure  are  present,  current  and  complete.  If  XDACS  detects  an 
error,  the  operation  is  terminated  at  the  end  of  the  prebuild  phase. 

5.  Creates  a  DCL  command  file  for  the  builder.  The  command  file  is 
deleted  after  the  LINK  operation  is  completed  or  terminated,  unless 
UNK/COMMAND  is  specified.  If  LINK/COMMAND  is  specified, 
the  command  file  is  retained  for  future  use,  and  the  build  phase  is 
not  carried  out. 

6.  Unless  the  /COMMAND  qualifier  is  specified,  performs  the  build 
phase  as  follows: 

a.  By  default  (LINK/WAIT),  the  command  file  generated  in  step 
5  is  executed  in  a  subprocess.  You  must  wait  for  the  build 
operation  to  terminate  before  issuing  another  command.  Note 
that  when  you  specify  the  /WAIT  qualifier  (the  default),  process 
logical  names  are  propagated  to  the  subprocess  generated  to 
execute  the  command  file. 
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b.  If  you  specify  the  /SUBMIT  qualifier,  the  builder  command  file 
is  submitted  as  a  batch  job. 

7.  If  the  /DEBUG  qualifier  is  included  in  the  command  line  the  debug 
symbol  table  information  is  placed  in  the  .XXE  file. 

8.  Creates  a  loadable  output  file  with  a  default  file  type  of  XXE. 

XDACS  output  originating  before  the  builder  is  invoked  is  reported 
to  your  terminal  by  default,  or  to  a  file  specified  with  the  /OUTPUT 
qualifier.  Diagnostics  are  reported  to  your  terminal,  by  default,  or  to 
a  log  file  if  the  LINK  command  is  executed  in  batch  mode  (XDACS 
UNK/SUBMIT). 

See  Developing  XD  Ada  Programs  on  VMS  Systems  for  the  MC68020  and  the 
XD  Ada  Version  1.2  New  Features  Manual  for  more  information  on  the  XD 
Ada  target-specific  builder  commands. 


Command  Qualifiers 

/AFTER  =  time 

Requests  that  the  batch  job  be  held  until  after  a  specific  hme,  when 
the  LINK  command  is  executed  in  batch  mode  (LINK/SUBMIT).  If  the 
specified  time  has  already  passed,  the  job  is  queued  for  immediate 
processing. 

You  can  specify  either  an  absolute  time  or  a  combination  of  absolute 
and  delta  time.  See  the  VMS  DCL  Concepts  Manual  (or  type  HELP 
Specify  Date-Time  at  the  DCL  prompt)  for  complete  information  on 
specifjhng  time  values. 

/  BATCH  _LOG  =  file-spec 

Provides  a  file  specification  for  the  batch  log  file  when  the  LINK  com¬ 
mand  is  executed  in  batch  mode  (LINK/SUBMIT). 

If  you  do  not  give  a  directory  specification  with  the  file-spec  option,  the 
batch  log  file  is  created  by  default  in  the  current  default  directory.  If 
you  do  not  give  a  file  specification,  the  default  file  name  is  the  job  name 
specified  with  the  /NAME- job-name  qualifier.  If  no  job  name  has  been 
specified,  the  program  library  manager  creates  a  file  name  comprising 
up  to  the  first  39  characters  of  the  first  unit  name  specified.  If  you 
specified  LINK/NOMAIN  and  no  job  name  and  there  is  a  wildcard 
character  in  the  first  unit  specified,  the  program  library  manager  uses 
the  default  file  name  XDACS.LINK,  The  default  file  type  is  LOG. 
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/BRIEF 

Directs  the  builder  to  produce  a  brief  image  map  file.  The  /BRIEF 
qualifier  is  valid  only  if  you  also  specify  the  /MAP  qualifier  with  the 
LINK  command.  The  /BRIEF  qualifier  is  incompatible  with  the  /FULL 
qualifier. 

A  brief  image  map  file  contains  onlv  the  following  sections; 

•  Object  module  information 

•  Segment  mapping  information 

•  Link  run  statistics 

See  also  the  descriphon  of  the  /FULL  qualifier. 

/COMMAND[=flle-spec] 

Controls  whether  the  builder  is  invoked  as  a  result  of  the  LINK  com¬ 
mand,  and  determines  whether  the  command  file  generated  to  invoke 
the  builder  is  saved.  If  you  specify  the  /COMMAND  qualifier,  XDACS 
does  not  invoke  the  builder,  and  the  generated  command  file  is  saved 
for  you  to  invoke  or  submit  as  a  batch  job. 

The  file-spec  option  allows  you  to  enter  a  file  specification  for  the  gen¬ 
erated  command  file.  The  default  directory  for  the  command  file  is  the 
current  default  directory.  By  default,  XDACS  provides  a  file  name  com¬ 
prising  up  to  the  first  39  characters  of  the  first  unit  name  specified.  If 
you  specified  LINK/NOMAIN  and  you  used  a  wildcard  character  in  the 
first  unit  name  specified,  the  program  librauy  manager  uses  the  default 
file  name  XDACS_LINK.  The  default  file  type  is  .COM.  No  wildcard 
characters  are  allowed  in  the  file  specification. 

By  default,  if  the  /COMMAND  qualifier  is  not  specified,  XDACS  deletes 
the  generated  command  file  when  the  LINK  command  completes 
normally  or  is  terminated. 

/DEBUG 
/NODEBUG  (D) 

Controls  whether  a  debugger  symbol  table  is  generated  in  the  loadable 
image  file. 

By  default,  no  debugger  symbol  table  is  created. 

/ELABORATION  =  file-spec 

Provides  a  file  specification  for  the  object  file  generated  by  the  LINK 
command.  The  file  is  retained  by  XDACS  only  when  the  /COMMAND 
qualifier  is  used;  that  is,  when  the  result  of  the  LINK  operation  is  to 
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produce  a  builder  command  file  for  future  use,  rather  than  to  invoke  the 
builder  immediately. 

The  generated  object  file  contains  the  code  that  directs  the  elaboration 
of  library  packages  in  the  closure  of  the  units  specified.  Unless  you  also 
specify  the  /NOMAIN  qualifier,  the  object  file  also  contains  the  image 
transfer  address. 

The  default  director^'  for  the  generated  text  file  is  the  current  default 
directory.  The  default  file  type  is  .ELB.  No  wildcard  characters  are 
allowed  in  the  file  specification. 

By  default,  if  you  do  not  specify  the  /ELABORATION  qualifier,  XDACS 
provides  a  file  name  comprising  up  to  the  first  39  characters  of  the  first 
unit  name  specified. 

By  default,  if  you  do  not  specify  the  /COMMAND  qualifier,  XDACS 
deletes  the  generated  object  file  when  the  LINK  command  completes 
normally  or  is  terminated. 

IFULL 

Directs  the  builder  to  produce  a  full  image  map  file,  which  is  the  most 
complete  image  map.  The  /FULL  qualifier  is  valid  only  if  you  also 
specify  the  /MAP  qualifier  with  the  LINK  command.  Also,  the  /FULL 
qualifier  is  incompatible  with  the  /BRIEF  qualifier. 

A  full  image  map  file  contains  the  following  sections: 

•  Object  module  information 

•  Segment  mapping  information 

•  Symbol  address  irrformation 

•  Exception  numbers 

•  Link  run  statistics 

IIMAGE[sfile’Spec]  (D) 

INOIMAGE 

Controls  whether  the  LINK  command  creates  a  loadable  image  file  and 
optionally  provides  a  file  specification  for  the  file.  The  default  file  type 
is  .XXE.  No  wildcard  characters  are  allowed  in  the  file  specification. 

By  default,  an  executable  image  file  is  created  with  a  file  name  compris¬ 
ing  up  to  the  first  39  characters  of  the  first  unit  name  specified. 
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/KEEP  (D) 

INOKEEP 

Controls  whether  the  batch  log  file  generated  is  deleted  after  it 
is  printed  when  the  LINK  conamand  is  executed  in  batch  mode 
(LINK/SUBMIT). 

By  default,  the  log  file  is  not  deleted. 

/LOG 

/NOLOG  (D) 

Controls  whether  a  list  of  all  the  units  included  in  the  executable  image 
is  displayed.  The  display  shows  the  units  according  to  the  order  of 
elaboration  for  the  program. 

By  default,  a  list  of  all  the  units  included  in  the  executable  image  is  not 
displayed. 

/MAIN  (D) 

INOMAIN 

Controls  where  the  image  transfer  address  is  to  be  found. 

The  /MAIN  qualifier  indicates  that  the  XD  Ada  unit  specified  deter¬ 
mines  the  image  transfer  address,  and  hence  is  to  be  a  main  program. 

The  /NOMAIN  qualifier  indicates  that  the  image  transfer  address  comes 
from  one  of  the  files  specified,  and  not  from  one  of  the  XD  Ada  units 
specified. 

By  default  (/MAIN),  only  one  XD  Ada  unit  can  be  specified,  and  that 
unit  must  be  an  XD  Ada  main  program. 

/MAPf=fl/e-spec; 

/NOMAP  (D) 

Controls  whether  the  builder  creates  an  image  map  file  and  optionally 
provides  a  file  specification  for  the  file.  The  default  directory  for 
the  image  map  file  is  the  current  directory.  The  default  file  name 
comprises  up  to  the  first  39  characters  of  the  first  unit  name  specified. 
The  default  file  type  is  .MAP.  No  wildcard  characters  are  allowed  in  the 
file  specification. 

If  neither  the  /BRIEF  nor  the  /FULL  qualifier  is  specified  with  the  /MAP 
qualifier,  /BRIEF  is  assumed. 

By  default,  no  image  map  file  is  created. 
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/NAME  =  job-name 

Specifies  a  string  to  be  used  as  the  job  name  and  as  the  file  name  for 
the  batch  log  file  when  the  LINK  command  is  executed  in  batch  mode 
(LINK/SUBMIT).  The  job  name  can  have  from  1  to  39  characters. 

By  default,  if  you  do  not  specify  the  /NAME  qualifier,  XDACS  creates 
a  job  name  comprising  up  to  the  first  39  characters  of  the  first  unit 
name  specified.  If  you  specify  LINK/NOMAIN  but  do  not  specify  the 
/NAME  qualifier,  and  you  use  a  wildcard  character  in  the  first  unit 
name  specified,  the  program  library  manager  uses  the  default  file  name 
XDACS_LINK.  In  these  cases,  the  job  name  is  also  the  file  name  of  the 
batch  log  file. 

/NOTIFY  (D) 

INONOTIFY 

Controls  whether  a  message  is  broadcast  when  the  LINK  command  is 
executed  in  batch  mode  (UNK/SUBMIT).  The  message  is  broadcast  to 
any  terminal  at  which  you  are  logged  in,  notifying  you  that  your  job  has 
been  completed  or  terminated. 

By  default,  a  message  is  broadcast. 

/OUTPUT  =  file-spec 

Requests  that  any  output  generated  before  the  builder  is  invoked  be 
written  to  the  file  specified  rather  than  to  SYSSOUTPUT.  Any  diagnostic 
messages  are  written  to  both  SYSSOUTPUT  and  the  file. 

The  default  directory  is  the  current  default  directory.  If  you  specify  a 
file  type  but  omit  the  file  name,  the  default  file  name  is  XDACS.  the 
default  file  type  is  .US.  No  wildcard  characters  are  allowed  in  the  file 
specification. 

By  default,  the  UNK  command  output  is  written  to  SYSSOUTPUT. 

IPRINTERl  =  queue-name] 

INOPRINTER  (D) 

Controls  whether  the  log  file  is  queued  for  printing  when  the  UNK 
command  is  executed  in  batch  mode  (LINK/SUBMIT)  and  the  batch  job 
is  completed. 

The  /PRINTER  qualifier  allows  you  to  specify  a  particular  print  queue. 
The  default  print  queue  for  the  log  file  is  SYSSPRINT. 

By  default,  the  log  file  is  not  queued  for  printing.  If  you  specify 
/NOPRINTER,  /KEEP  is  assumed. 
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lOUEUE  =  queue-name 

Specifies  the  batch  job  queue  in  which  the  job  is  entered  when  the 
LINK  command  is  executed  in  batch  mode  (LINK/SUBMIT). 

By  default,  if  the  /QUEUE  qualifier  is  not  specified,  the  job  is  placed  in 
the  default  system  batch  job  queue,  SYSSBATCH. 

ISELECTIVE  (D) 

/NOSELECTIVE 

Specifies  whether  selective  lirddng  is  performed. 

Performing  selective  iiirking  ensures  that  only  subprograms  that  are 
called  will  be  linked  into  the  program  image.  Subprograms  within  the 
closure  of  the  main  program  that  are  not  actually  called  will  be  omitted 
from  the  image  file.  Selective  linking  produces  a  program  image  that 
has  been  optimized  according  to  size. 

Non-selective  liirking  ensures  that  all  defined  subprograms  are  linked 
into  the  image. 

By  default,  selective  linking  is  performed. 

/SUBMIT 

Directs  XDACS  to  submit  the  command  file  generated  for  the  builder 
to  a  batch  queue.  You  can  continue  to  issue  commands  in  your  current 
process  without  waiting  for  the  batch  job  to  complete.  The  builder 
output  is  written  to  a  batch  log  file. 

By  default,  the  generated  command  file  is  executed  in  a  subprocess 
(UNK/WAIT). 

/WAIT 

Directs  XDACS  to  execute  the  command  file  generated  for  the  builder 
in  a  subprocess.  Execution  of  your  current  process  is  suspended  until 
the  subprocess  completes.  The  builder  output  is  written  directly  to 
your  terminal.  Note  that  process  logical  names  are  propagated  to  the 
subprocess  generated  to  execute  the  command  file. 

By  default,  XDACS  executes  the  command  file  generated  for  the  builder 
in  a  subprocess:  you  must  wait  for  the  subprocess  to  terminate  before 
you  can  issue  another  command. 
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Parameter  Qualifiers 

/LIBRARY 

Indicates  that  the  associated  input  file  is  an  object  module  library  to  be 
searched  for  modules  to  resolve  any  undefined  symbols  in  the  input 
files.  The  default  file  type  is  .XLB. 

By  default,  if  you  do  not  specify  the  /LIBRARY  qualifier,  the  file  is 
assumed  to  be  an  object  file  with  a  default  file  type  of  .XOB. 

/MAPPING 

Indicates  that  the  associated  input  file  is  a  mapping  definition  file. 
Mapping  definition  files  control  the  location  of  the  program  on  the 
target  system.  The  default  file  type  is  .MPD. 

By  default,  if  you  do  not  specify  the  /MAPPING  qualifier,  the  file  is 
assumed  to  be  an  object  file  with  a  default  file  type  of  .XOB. 

/TARGET 

Indicates  that  the  associated  input  file  is  a  target  definition  file.  Target 
definition  files  describe  the  target  system's  memory.  The  default  file 
type  is  .TGD. 

By  default,  if  you  do  not  specify  the  /TARGET  qualifier,  the  file  is 
assumed  to  be  an  object  file  with  a  default  file  tj^e  of  .XOB. 


Examples 

1.  XDACS>  LINK  CONTROL_LOOP 
%ACS-I-CL_LINKING,  Invoking  the  XD  Ada  Builder 

The  LINK  command  forms  the  closure  of  the  unit  CONTROL, 
LOOP,  which  is  an  XD  Ada  main  program,  creates  a  builder  com¬ 
mand  file  and  package  elaboration  file,  then  invokes  the  command 
file  in  a  spawned  subprocess. 

2.  XDACS>  LINK/SUBMIT  CONTROL_LOOP  LOOP_FUNCTIONS/LI BRARY 

%ACS-I-CL_SUBMITTED,  Job  CONTROL_LOOP  (queue  ALL_BATCH,  entry  1341 
started  on  FAST_BATCH 

The  LINK  command  instructs  the  builder  to  link  the  closure  of  the 
XD  Ada  main  program  CONTROL  LOOP  against  the  library  LOOP, 
FUNCTIONS.XLB.  The  /SUBMIT  qualifier  causes  XDACS  to  submit 
the  builder  command  file  as  a  batch  job. 
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3.  XDACS>  LINK/NOMAIN  FLUID_VOLUME , COUNTER  MONITOR. XCB 
%ACS-I-CL_L1NKING,  Invoking  the  XD  Ada  Builder 

The  LINK  command  builds  the  XD  Ada  units  FLUID_VOLUME 
and  COUNTER  with  the  foreign  object  file  MONITOR. XOB.  The 
/NOMAIN  qualifier  tells  the  builder  that  the  image  transfer  address 
is  in  the  foreign  file. 
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APPENDIX  C 

APPENDIX  F  OF  THE  Ada  STANDARD 


The  only  allowed  implementation  dependencies  correspond  to  implementation-dependent  pragmas, 
to  certain  machine-dependent  conventions  as  mentioned  in  Chapter  13  of  the  Ada  Standard,  and  to 
certain  allowed  restrictions  on  representation  clauses.  The  implementation-dependent  characteristics 
of  this  Ada  implementation,  as  described  in  this  Appendix,  are  provided  by  the  customer.  Unless 
specifically  noted  otherwise,  references  in  this  Appendix  are  to  compiler  documentation  and  not  to 
this  report.  Implementation-specific  portions  of  the  package  STANDARD,  which  are  not  a  part  of 
Appendix  F,  are: 


package  STANDARD  is 

type  INTEGER  is  range  -2147483648  ..  2147483647; 

type  SHORTJNTEGER  is  range  -32768  ..  32767; 

type  SHORT_SHORT_INTEGER  is  range  -128  ..  127; 

type  FLOAT  is  digits  6  range  -(2**128  -  2**104)  ..  2**128  -  2**104; 

type  LONG_FLOAT  is  digits  15  range  -(2**1024  -2**971)  ..  2**1024  -  2**971; 

type  LONG_LONG_FLOAT  is  digits  18  range  -(2**16384  -  2**16320)  ..  2**16384  -  2**16320; 

type  DURATION  is  delta  l.OE-4  range  -131072.0000  ..  131071.9999; 

end  STANDARD; 
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XD  Ada  MC68040/ARTX  Version  1.2 


Chapter  1 

Introduction 


The  target  name  for  XD  Ada  MC68040  is  "MC68040'',  and  not 
"MC68020".  This  applies  throughout  the  manual. 
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F.3  Specification  of  Package  SYSTEM 

The  package  SYSTEM  for  the  MC68040  configuratioi\  differs  from  that 
of  the  standard  MC68020  as  follows: 


F.3.1  Package  SYSTEM  for  the  MC68040  Target 

For  MC68040,  the  system  description  has  been  redefined  as  follows: 

typ«  NAME  is  (MC68040); 

SYSTEM_NAME  ;  eoaataat  NAME  ;»  MC68040; 

STORAGi_UNIT  !  eoaataat  i-  8; 

MEMORY  ilZE  t  eoaataat  :•  2--31-1; 
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NOTE 

This  appendix  is  not  part  of  the  standard  definition  of  the 
Ada  progranuning  language. 

This  appendix  summarizes  the  following  implementation-dependent 
characteristics  of  XD  Ada: 

•  Listing  the  XD  Ada  pragmas  and  attributes. 

•  Giving  the  specification  of  the  package  SYSTEM. 

•  Presenting  the  restrictions  on  representation  clauses  and  unchecked 
type  conversions. 

•  Giving  the  conventions  for  names  denoting  implementation- 
dependent  components  in  record  representation  clauses. 

•  Giving  the  interpretation  of  expressions  in  address  clauses. 

•  Presenting  the  implementation-dependent  characteristics  of  the 
input-output  packages. 

•  Presenting  other  implementation-dependent  characteristics. 

References  all  apply  to  sections  in  the  XD  Ada  MC68020  Supplement  to 
the  Ada  Language  Reference  Manual. 
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Implementation-Dependent  Pragmas 


XD  Ada  provides  the  following  pragmas,  which  are  defined  elsewhere 
in  the  text.  In  addition.  XD  Ada  restricts  the  predefined  language 
pragmas  INLINE  and  INTERFACE,  provides  pragma  VOLATILE  in 
addition  to  pragma  SHARED,  and  provides  pragma  SUPPRESS_ALL  in 
addition  to  pragma  SUPPRESS.  See  Annex  B  for  a  descriptive  pragma 
summary. 

•  CALL.SEQUENCE.FUNCnON  (see  Annex  B) 

•  CALL.SEQUENCE.PROCEDURE  (see  Annex  B) 

•  EXPORT.EXCEPTION  (see  Section  13.9a.3.2) 

•  EXPORT.FUNCnON  (see  Section  13.9a.l.2) 

•  EXPORT.OBJECT  (see  Section  13.9a.2.2) 

•  EXPORT.PROCEDURE  (see  Section  13.9a.l.2) 

•  IMPORT.EXCEPTION  (see  Section  13.9a.3.1) 

•  IMPORT.FUNCnON  (see  Section  13.9a.l.l) 

•  IMPORT.OBJECT  (see  Section  13.9a.2.1) 

•  IMPORT.PROCEDURE  (see  Section  13.9a.  1.1) 

•  LEVEL  (see  Section  13.5.1) 

•  LINK_OPTION  (see  Annex  B) 

•  SUPPRESS. ALL  (see  Section  11.7) 

•  TITLE  (see  Annex  B) 

•  VOLATILE  (see  Section  9.11) 


F.2  Implementation-Dependent  Attributes 

XD  Ada  provides  the  following  attributes,  which  are  defined  elsewhere 
in  the  text.  See  Appendix  A  for  a  descriptive  attribute  summary. 

•  BIT  (see  Section  13.7.2) 

•  MACHINE.SIZE  (see  Section  13.7.2) 

•  TYPE.CLASS  (see  Section  13. 7a. 2) 
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F.3  Specification  of  the  Package  System 

The  package  SYSTEM  for  the  MC68020  is  as  follows: 

paekag*  sySTEM  la 

typa  NAME  la  (NC68020); 

SYSTEM_NAME  :  eoaataat  NAME  Mce8020; 

STORAGi_UNIT  !  coBataat  8; 

MEMORY_ilZE  i  eoaataat  2**31-1; 

MIN_INT  I  eoaataat  -(2**31); 

MAX_IMT  :  eoaataat  2**31-1; 

MAX_OIGITS  :  eoaataat  :•  18; 

MAX~HANTISSA  :  eoaataat  31; 

FINi_DELTA  :  eoaataat  2.0** (-31); 

TICK  :  eoaataat  162. SB-6; 

aabtypo  PRIORITY  la  INTEGER  raago  0  ..  15; 

aubtypo  LEVEL  la  INTEGER  caago  0  ..  7; 

—  Addreaa  type 

typa  ADDRESS  la  private; 

AODRESS_ZERO  t  eoaataat  ADDRESS; 
typo  ADDRESS_INT  la  raago  MIN_INT  ..  MAX_INT; 
fuBCtlea  TO_ADDRESS  (X  :”aDDRESS_INT) 

fuaetloa  TO_ADDRBSS  (X  i  {universal  integer)) 

fuaetloa  To2aDDRESS_INT  (X  j  ADDRESS) 

fuaetloa  (LEFT  :  ADDRESS;  RIGHT  :  ADDRESS_INT)  rotura  ADDRESS; 

fuaetloa  (LEFT  !  ADDRESS_INT;  RIGHT  :  ADDRESST  rotura  ADDRESS; 

fuaetloa  (LEFT  :  ADDRESS?  RIGHT  :  ADDRESS)  rotura  ADDRESS_INT; 

fuaetloa  *-*  (LEFT  i  ADDRESS;  RIGHT  :  ADDRESS.INT)  rotura  ADDRESS? 

—  fuaetloa  (LEFT,  RIGHT  «  ADDRESS)  rotura  BOOLEAN; 

—  fuaetloa  */-’  (LEFT,  RIGHT  !  ADDRESS)  rotura  BOOLEAN; 

fuaetloa  '<■  (LEFT,  RIGHT  <  ADDRESS)  rotura  BOOLEAN; 

fuaetloa  ■<-'  (LEFT,  RIGHT  s  ADDRESS)  rotura  BOOLEAN; 

fuaetloa  ->’  (LEFT,  RIGHT  >  ADDRESS)  rotura  BOOLEAN; 

fuaetloa  *>-’  (LEFT,  RIGHT  :  ADDRESS)  rotura  BOOLEAN; 

--  Note  that  because  ADDRESS  is  a  private  type 
--  the  functions  *»■  and  */«"  are  already  available 

--  Generic  functions  used  to  access  memory 
goBoric 

typ«  TARGET  la  private; 

fuaetloa  FETCH_FROM_ADDRESS  (A  !  ADDRESS)  rotura  TARGET; 
goaorle 

TARGET  !•  privet#; 

procedure  ASSIGN^TO^ADDRESS  (A  :  ADDRESS;  T  :  TARGET); 
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rotura  ADDRESS; 
rotura  ADDRESS; 
rotura  ADDRESS  INT; 


typ«  TYPE_CLASS  is  ( TYPE_CLASS_ENUMERATION, 

T YPE_CLASS_ I NTEGER , 
TYPE_CLASS_FIXED_POINT, 
TYPE_CLASS~FLOAtInG  POINT, 
TYPE_CLASS~ARRAY , 
TYPE_CLASS~REC0RD, 
TYPE~CLASS~ACCESS , 

type~class"task, 

TYPE_CLASs”aDDRESS ) ; 


XO  Ada  hardware-oriented  types  and  functions 


type  BIT_ARRAY  Is  array  (INTEGER  raaga  <>) 
pragma  PACK ( B I T_ARRAY ) ; 

subtype  BIT_ARRAY_8  la  BIT_ARRAY  (0  ..  7 ) ; 

subtype  BIT_ARRAY~16  la  BIT_ARRAY  (0  ..  15); 

subtype  BIT~ARRAY~32  Is  BIT_ARRAY  (0  •.  31); 

subtype  BIT~ARRAY~64  is  BIT^ARRAY  (0  ..  63); 

type  UNSIGNio_BYTi  la  ruga  0  ..  255; 
tor  UNSIGNBD_8YTB'SIZB  use  8; 

fuaetlea  -nof  (LBFT  :  UNSIGNBD_BYTE ) 

fuaetlen  -and"  (LBFT,  RIGHT  :  UNSIGNED^BYTE) 
fuaetlea  "or"  (LBFT,  RIGHT  i  UNS1GNBD~BYTE) 
fuaetlea  'xor*  (LEFT,  RIGHT  :  UNSIGNBD~BYTE) 


of  BOOLEAN; 


retura  UNSIGNBD_BYTB; 
retura  UNSIGNED_BYTB; 
retura  UNSIGNED~BYTB; 
retura  UNSIGNBD_BYTB; 


fuaetlea  T0_UNS1GNED_BYTE  (X  t  8IT_ARRAY_8)  retura  UNS1GNED_BYTE: 
fuaetlea  To"bIT_ARRAY_8  (X  s  UNSIGNED_BYTE)  retura  BIT_ARRAy38; 


type  UNSIGNED_BYTE_ARRAY  la  array  (INTEGER  raaga  <>)  ef  UNSIGNED_BYTE; 


type  UNSIGNED_W0R0  is  raage  0  ..  65535; 
fer  UNSIGNED_WORO‘SIZE  use  16; 


fuaetlea  'not'  (LEFT  :  UNSIGNED_WORO)  retura  UN5IGNED_W0RD; 

fuaetlea  -and*  (LEFT,  RIGHT  :  UNSIGNBD^WORO)  retura  UNSIGNBD~HORD; 
fuaetlea  'or'  (LEFT,  RIGHT  >  UNSIGNEd'horD)  retura  UNSIGNBD^WORD; 
fuaetlea  'xor*  (LBFT,  RIGHT  :  UNSIGNBD^WORD)  retura  UNSISNEd'horc; 

fuaetlea  T0_UNSIGNED_W0RD  (X  t  BIT_ARRAY_16 )  retura  UNS1GNED_W0RD; 
fuaetlea  T0_81T_ARRAy_16  (X  »  0NsIgnbd_W0RD)  retura  BIT_ARRAY_16; 

type  UNSIGNED_WORO_ARRAY  la  array  (INTEGER  ruga  <>)  ef  UN5IGNBD_H0R0; 


type  UNSIGNED_LONGWORD  la  ruge  M1N_INT  ..  MAX_INT: 
fer  UNSIGNED_LONGWORD'SIZE  use  32; 

fuaetlea  "not*  (LEFT  t  UNSIGNED_LONGWORD)  retura  UNSIGNED_LONG»tORD; 

fuaetlea  "and*  (LEFT,  RIGHT  :  UNSIGNED~LONGNORD)  retura  UNSIGNED~LONGHORD; 

fuaetlea  "or"  (LEFT,  RIGHT  :  UNSIGNED^LONGWORD)  retura  UNSIGNED~LONGWORD; 

fuaetlea  "xor”  (LEFT,  RIGHT  I  UNSIGNED^LONGWORD)  retura  UNSIGNEd”lONGWORD; 

fuaetlea  TO_UNSIGNED_LONGWORD  (X  s  BIT_ARRAY_32 )  retura  UNSIGNED_LONGWORD; 
fuaetlea  To3bit_ARRAY_32  (X  ;  UNSIGNiD_WORD)  retura  BIT_ARRAY_32 ; 

type  UNSIGNiiD_LONGWORD_ARRAY  la  array  (INTEGER  raage  <>)  of  UNSIGNED_LONGWORD; 
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Conventi 

onal  names  for 

static  subtypes  ol 

type 

UN  S I GNED_  LONGWORD 

■ubtyp* 

UNSIGNED_ 

1 

!■ 

UNSIGNED 

LONGWORD 

range 

0 

..  2**  1-1 

■ubtyp* 

unsigned” 

2 

!■ 

unsigned! 

LONGNORD 

range 

0 

..  2**  2-1 

■ubtyp* 

unsigned” 

3 

1* 

unsigned! 

LONGWORD 

range 

0 

..  2**  3-1 

•ubtyp* 

unsigned! 

4 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2**  4-1 

■ubtyp* 

unsigned! 

5 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2**  5-1 

■ubtyp* 

unsigned! 

6 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2**  6-1 

■ubtyp* 

unsigned! 

7 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2*«  7-1 

■ubtyp* 

unsigned! 

a 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2**  8-1 

■ubtyp* 

unsigned! 

9 

!■ 

unsigned! 

LONGWORD 

range 

0 

.  .  2**  9-1 

■ubtyp* 

unsigned! 

10 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2»*10-1 

■ubtyp* 

unsigned! 

11 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2**11-1 

■ubtyp* 

unsigned! 

12 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2»*12-1 

■ubtyp* 

unsigned! 

13 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2**13-1 

■ubtyp* 

unsigned! 

14 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2*«14-1 

■ubtyp* 

unsigned! 

15 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2«*15-1 

■ubtyp* 

unsigned! 

16 

i* 

unsigned! 

LONGWORD 

range 

0 

..  2»*16-1 

■ubtyp* 

unsigned! 

17 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2«*17-1 

■ubtyp* 

unsigned! 

16 

Im 

unsigned! 

LONGWORD 

range 

0 

2«*18-1 

■ubtyp* 

unsigned! 

19 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2«*19-1 

■ubtyp* 

unsigned! 

20 

t* 

unsigned! 

LONGWORD 

range 

0 

..  2**20-l 

■ubtyp* 

unsigned! 

21 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2**21-1 

■ubtyp* 

unsigned! 

22 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2**22-l 

■ubtyp* 

unsigned! 

23 

!■ 

unsigned! 

LONGNORD 

range 

0 

..  2*»23-l 

■ubtyp* 

unsigned! 

24 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2*«24-l 

■ubtyp* 

unsigned! 

25 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2»«25-l 

■ubtyp* 

unsigned! 

26 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2**26-l 

■ubtyp* 

unsigned! 

27 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2**27-l 

■ubtyp* 

unsigned! 

28 

1* 

unsigned! 

LONGWORD 

range 

0 

..  2*«28-l 

■ubtyp* 

unsigned! 

29 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2»*29-l 

■ubtyp* 

unsigned! 

30 

1* 

unsigned! 

LONGWORD 

range 

0 

..  2**30-l 

■ubtyp* 

unsigned! 

31 

!■ 

unsigned! 

LONGWORD 

range 

0 

..  2**31-3 

private 

—  Not  shown 
•ad  SYSTEM; 


F.4  Restrictions  on  Representation  Clauses 

The  representation  clauses  allowed  in  XD  Ada  are  length,  enumeration, 
record  representation,  and  address  clauses. 

In  XD  Ada,  a  representation  clause  for  a  generic  formal  type  or  a  type 
that  depends  on  a  generic  formal  type  is  not  allowed.  In  addition,  a 
representation  clause  for  a  composite  type  that  has  a  component  or 
subcomponent  of  a  generic  form2d  type  or  a  type  derived  from  a  generic 
formal  t^e  is  not  aUowed. 
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Restrictions  on  length  clauses  are  specified  in  Section  13.2;  restrictions 
on  enumeration  representation  clauses  are  specified  in  Section  13.3;  and 
restrictions  on  record  representation  clauses  are  specified  in  Section 
13.4. 


F.5  Conventions  for  Implementation-Generated  Names 
Denoting  Implementation-Dependent  Components  in 
Record  Representation  Clauses 

XD  Ada  does  not  allocate  implementation-dependent  components  in 
records. 


F.6  Interpretation  of  Expressions  Appearing  in  Address 
Clauses 

Expressions  appearing  in  address  clauses  must  be  of  the  type  ADDRESS 
defined  in  package  SYSTEM  (see  Section  13.7a.l  and  Section  F.3). 

XD  Ada  allows  address  clauses  for  variables  (see  Section  13.5).  For 
address  clauses  on  variables,  the  address  expression  is  interpreted  as  a 
Motorola  full  32-bit  address. 

XD  Ada  supports  address  clauses  on  task  entries  to  allow  interrupts  to 
cause  a  reschedule  directly.  For  address  clauses  on  task  entries,  the 
address  expression  is  interpreted  as  a  Motorola  exception  vector  offset. 

In  XD  Ada  for  MC68020,  values  of  type  SYSTEM.ADDRESS  are  inter¬ 
preted  as  integers  in  the  range  0  ..  2^^  -1.  As  SYSTEM.ADDRESS  is 
a  private  type,  the  only  operations  allowed  on  objects  of  this  type  are 
those  given  in  package  SYSTEM. 


F.7  Restrictions  on  Unchecked  Type  Conversions 

XD  Ada  supports  the  generic  function  UNCHECKED_CONVERSION 
with  the  restrictions  given  in  Section  10.3.2. 
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F.8  Implementation-Dependent  Characteristics  of 
Input-Output  Packages 


The  packages  SEQUENTIAL_IO  and  DIRECT_IO  are  implemented  as 
null  packages  that  conform  to  the  specification  given  in  the  Reference 
Manual  for  the  Ada  Programming  Language.  The  packages  raise  the  ex¬ 
ceptions  specified  in  Chapter  14  of  the  Reference  Manual  for  the  Ada 
Programming  Language.  The  three  possible  exceptions  that  are  raised  by 
these  packages  are  given  here,  in  the  order  in  which  they  are  raised. 


Exception 

When  Raised 

STATUS.ERROR 

Raised  by  an  attempt  to  operate  upon  or  close  a  file 
that  is  not  open  (no  files  can  be  opened). 

NAME.ERROR 

Raised  if  a  file  name  is  given  with  a  call  of  CREATE 
or  OPEN. 

USE.ERROR 

Raised  if  exception  STATUS.ERROR  is  not  raised. 

MODE.ERROR  cannot  be  raised  since  no  file  can  be  opened  (therefore 
it  cannot  have  a  current  mode). 

The  predefined  package  LOW_LEVEL_IO  is  not  provided. 


F.8.1  The  Package  TEXTJO 

The  package  TEXT_IO  conforms  to  the  specification  given  in  the 
Reference  Manual  for  the  Ada  Programming  Language.  String  input- 
output  is  implemented  as  defined.  File  input-output  is  supported  to 
STANDARD.INPUT  and  STANDARD.OUTPUT  only.  The  possible 
exceptions  that  are  raised  by  package  TEXT_IO  are  as  follows; 
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Exception 

When  Raised 

STATUS.ERROR 

Raised  by  an  attempt  to  operate  upon  or  dose  a  file 
that  is  not  open  (no  files  can  be  opened). 

NAME.ERROR 

Raised  if  a  file  name  is  given  with  a  call  of  CREATE 
or  OPEN. 

MODE.ERROR 

Raised  by  an  attempt  to  read  from,  or  test  for 
the  end  of.  STANDARD.OUTPUT,  or  to  write  to 
STANDARD.INPUT. 

END.ERROR 

Raised  bv  an  attempt  to  read  past  the  end  of 
STANDARDJNPUT. 

USE.ERROR 

Raised  when  an  unsupported  operation  is  attempted, 
that  would  otherwise  be  legal. 

The  type  COUNT  is  defined  as  follows: 

typ«  COUNT  is  rang*  0  ..  INTEGER' LAST; 

The  subtype  FIELD  is  defined  as  follows 

typ*  FIELD  Is  INTEGER  rang*  0  ..  132; 


F.8.2  The  Package  lO.EXCEPTIONS 

The  specification  of  the  package  lO.EXCEPTIONS  is  the  same  as  that 
given  in  the  Reference  Manual  for  the  Ada  Programming  Language. 


F.9  Other  Implementation  Characteristics 

Implementation  characteristics  associated  with  the  definition  of  a  main 
program,  various  numeric  ranges,  and  implementation  limits  are  sum¬ 
marized  in  the  following  sections. 


F.9.1  Definition  of  a  Main  Program 

Any  library  procedure  can  be  used  as  a  main  program  provided  that  it 
has  no  formal  parameters. 


F-8  Implementation-Dependent  Characteristics 


F.9.2  Values  of  Integer  Attributes 

The  ranges  of  values  for  integer  types  declared  in  package  STANDARD 
are  as  follows; 


SHORT.SHORT.INTEGER 

-U  .. 

i!  -1 

(-128  . 

.  127) 

SHORT.INTEGER 

-2‘*  . 

.  2'=  -1 

(-32768  . 

.  32767) 

INTEGER 

-2^’  . 

.  2^'  -1 

(-2147483648  . 

.  2147483647) 

For  the  package  TEXT_IO,  the  range  of  values  for  types  COUNT  and 
FIELD  are  as  follows: 

COUNT  0  ..  2^'  -1  (0  ..  2147483647) 

HELD  0  ..  132 


F.9.3  Values  of  Floating-Point  Attributes 

Floating-point  types  are  described  in  Section  3.5.7.  The  representation 
attributes  of  floating-point  types  are  summarized  in  the  following  table: 
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FLOAT 

LONG.FLOAT 

LONG.LONG.FLOAT 

DIGITS 

6 

15 

18 

SIZE 

32 

64 

96 

MANTISSA 

21 

51 

61 

EMAX 

84 

204 

244 

EPSILON 

2-20 

2-50 

2—60 

SMALL 

2-85 

2-205 

2-245 

LARGE 

2^4  2^3 

2204  _2lS3 

2244_2l83 

SAFE.EMAX 

125 

1021 

16382 

SAFE.SMALL 

2-126 

2-1022 

2-15383 

SAFE.IARGE 

2l25_2lM 

21021  _2920 

215382  _2l5321 

FIRST 

_(2l28  2^^) 

_^2'‘*5_2l5320^ 

LAST 

2i2ft_2*®* 

2i02«_2’^' 

215384  _2l5320 

MACHINE.RADIX 

2 

2 

2 

MACHINE.MANTISSA 

24 

53 

64 

MACHINE.EMAX 

128 

1024 

16384 

MACHINE.EMIN 

-125 

-1021 

-16382 

MACHINE.ROUNDS 

FALSE 

FALSE 

FALSE 

MACHINE.OVERFLOWS 

FALSE 

FALSE 

FALSE 
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F.9.4  Attributes  of  Type  DURATION 


The  values  of  the  significant  attributes  of  type  DURATION  are  as 
follows; 


DURATION 'DELTA 
DURATION 'SMALL 
DURATION 'HRST 
DURATION 'LAST 


l.E-4 

2#1.0#E-14 

-131072.0000 

131071.9999 


(10-^ 

(2-M) 


F.9.5  Impiementation  Limits 


Limit  Detchption 

255  Maximum  identifier  length  (number  of  characters) 

255  Maximum  number  of  characters  in  a  source  line 

2'”  Maximum  number  of  library  units  and  subunits  in  a  compilation 

closure' 

2'^  Maximum  number  of  library  units  and  subunits  in  an  execution 

closure* 

2'*  -1  Maximum  number  of  enumeration  literals  in  an  enumeration 

type  defiiution 

2“  -1  Maximum  number  of  lines  in  a  source  file 

2^'  -1  Maximum  number  of  bits  in  any  object 

2'*  -1  Maximum  number  of  exceptions 


'Hie  compilation  closure  of  a  given  unit  is  the  total  set  of  units  that  the  given  unit 
depends  on,  directly  and  indirectly. 

^The  execution  closure  of  a  given  unit  is  the  compilation  closure  plus  all  associated 
secondary  units. 
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Appendix  F 

Implementation-Dependent 

Characteristics 


This  appendix  describes  Version  1.2  additions  to  the  range  of 
implementation-dependent  pragmas,  and  enhancements  to  the  func¬ 
tionality  of  Package  TEXT.IO.  It  supplements  information  supplied  in 
the  Version  1.0  version  of  this  appendix. 


F.1  Implementation-Dependent  Pragmas 

XD  Ada  MC68020  Version  1.2  supplies  three  new  pragmas,  DIRECT 
INTERRUPT.ENTRY,  IDENT  and  TIME.SUCE.  In  the  following  full 
list  of  supported  pragmas,  references  refer  to  sections  in  the  XD  Ada 
MC6802Q  Supplement  to  the  Ada  Language  Reference  Manual,  unless  updated 
by  sections  supplied  in  this  manual. 

•  CALL_SEQUENCE_FUNCTION  (see  Annex  B) 

•  CALL.SEQUENCE.PROCEDURE  (see  Annex  B) 

•  DmECT.INTERRUPT.ENTRY  (see  Section  13.5.1) 

•  EXPORT.EXCEPTION  (see  Section  13.9a.3.2) 

•  EXPORT.FUNCnON  (see  Section  13.9a.  1.2) 

•  EXPORT.OBJECT  (see  Section  13.9a.2.2) 

•  EXPORT.PROCEDURE  (see  Section  13.9a.  1.2) 

•  IDENT  (see  Atmex  B) 

•  IMPORT.EXCEPTION  (see  Section  13.9a.3.1) 

•  IMPORT.FUNCnON  (see  Section  13.9a.l.l) 
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•  IMPORT_OBIECT  (see  Section  13.9a.2.1) 

•  IMPORT.PROCEDURE  (see  Section  13.9a.l.l) 

•  LEVEL  (see  Section  13.5.1) 

•  LINK_OPnON  (see  Annex  B) 

•  SUPPRESS_ALL  (see  Section  11.7) 

•  TITLE  (see  Annex  B) 

•  TIME_SLICE  (see  Section  9.8a) 

•  VOLATILE  (see  Section  9.11) 


F.8.1  The  Package  TEXTJO 

The  package  TEXT_IO  conforms  to  the  specification  given  in  the 
Reference  Manual  for  the  Ada  Programming  Language.  Package  TEXT.IO,  as 
supplied  by  XD  Ada  MC68020  Version  1.2,  has  changed  as  follows: 

•  The  Run-Time  System  now  supports  asynchronous  input-output 
operations,  where  a  TEXT_IO  operation  will  cause  only  the  task 
that  performs  tlie  operation  to  be  suspended  awaiting  its  com¬ 
pletion,  rather  than  all  the  tasks  in  the  program.  You  enable  this 
facility  by  compiling  the  file  XDADA$TARGET_SOURCE:ASYNC_ 
TERMINAL.IO.ADA  into  your  program  library,  as  described  in 
the  XD  Ada  MC68020  Version  1.2  New  Features  Manual.  You  dis¬ 
able  asynchronous  TEXT^IO  operations  by  compiling  the  file 
XDADA$TARGET_SOURCE;TERMINAL_IO.ADA  into  your  pro¬ 
gram  library. 

•  Support  is  provided  for  target  input-output  to  be  directed  to  logical 
input  and  output  streams  on  the  host.  This  facility  is  available  for 
both  the  XDDEBUG  and  XDRUN  commands. 

Input  and  output  are  buffered.  For  input,  all  characters  up  to  an 
end  of  line  or  end  of  page  are  iiuide  available  to  the  target  program 
before  further  characters  are  read.  For  output,  the  buffer  is  flushed 
following  an  end  of  line  or  end  of  page.  See  the  XD  Ada  MC68020 
Version  1.2  New  Features  Manual  for  details  of  the  TEXT_IO  data 
objects  that  control  this  behavior. 

Note  that  if  XDADASINPLTr  and  XDADASOUTPUT  are  defined  but 
opening  the  file  gives  an  error,  for  example  the  file  does  not  exist, 
the  filename  is  invalid  or  no  read/write  permission  is  assigned,  the 
file  is  treated  as  empty. 
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The  text  in  this  chapter  lists  the  differences  between  XD  Ada  MC68040 
and  XD  Ada  MC68020,  as  described  in  the  XD  Ada  MC68020  Supplement 
to  the  Ada  Language  Reference  Manual. 


13.7  The  Package  SYSTEM 

The  following  information  replaces  the  MC68020  supplement  to  para¬ 
graph  5: 

In  XD  Ada  MC68040,  the  enumeration  literal  for  SYSTEM.NAME  is 
MC68040. 


13,7.1  Systom-Oependont  Named  Numbers 


13-1 


Chapter  13 

Representation  Clauses  and 
Implementation-Dependent 

Features 


This  chapter  describes  XD  Ada  MC68020  Version  1.2  interrupt  handling. 
In  particular,  it  describes  the  handling  of  direct  interrupt  entries,  and 
use  of  pragma  DIRECT_INTERRUPT_ENTRY. 


13.5.1  Interrupts 

The  following  information  supplements  all  of  this  section: 

Unlike  VAX  Ada,  XD  Ada  supports  interrupts.  The  address  in  the  use 
clause  is  the  address  of  the  interrupt.  The  address  is  interpreted  as  an 
offset  in  bytes  from  the  vector  base  register.  For  details  of  MC68020 
exception  vector  assignments,  see  Table  6-2  of  the  MC68020  32-Bit 
Microprocessor  User's  Manual.  Note  that  when  assigning  vectors,  the 
offset  is  a  multiple  of  four  of  the  vector  number.  In  this  way,  vector 
number  64  (decimal)  would  have  the  hexadecimal  offset  100. 

In  addition  to  support  for  normal  Ada  interrupt  entries,  XD  Ada 
movides  the  additional  pranas  LEVEL  and  DIRECT_INTERRUPT_ 
ENTRY.  Pragma  LEVEL  is  given  for  a  task  type,  or  single  task  of  anony¬ 
mous  type,  and  gives  the  level  for  its  interrupts.  Pragma  DIRECT. 
INTERRUPT.ENTRY  is  used  to  connect  an  interrupt  entry  directly  to  the 
required  interrupt  vector,  and  is  described  below. 
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There  are  two  ways  an  interrupt  entry  can  be  handled,  according  to 
whether  or  not  the  task  has  a  pragma  LEVEL.  The  XD  Ada  MC68020 
Run-Time  Reference  Manual  gives  examples  of  interrupt  handlers. 

Tasks  with  interrupt  entries  but  no  pragma  LEVEL  run  at  interrupt  level 
0  only  while  accepting  an  interrupt  in  a  rendezvous.  Other  interrupts  of 
the  same  level  or  lower  levels  are  inhibited  while  in  the  handler.  It  is, 
however,  possible  to  lose  interrupts  with  this  method. 

Tasks  with  interrupt  entries  and  a  pragma  LEVEL  always  run  at  interrupt 
level,  whether  inside  or  outside  a  rendezvous.  This  enables  the  user  to 
avoid  losing  interrupts. 

An  interrupt  entry  to  a  task  with  the  pragma  LEVEL  behaves  like  an 
ordinary  entry  call.  An  interrupt  entry  to  a  task  with  no  pragma  LEVEL 
behaves  like  a  conditional  entry  call.  If  there  is  an  accept  statement 
waiting  for  the  interrupt,  the  body  of  the  accept  statement  is  executed 
immediately.  When  the  body  is  complete,  the  task  is  inserted  in  the 
ready  queue  and  the  interrupt  completed  by  a  retum-from-interrupt 
instruction.  The  accept  statement  can  call  subprograms  and  make  entry 
calls,  but  must  not  suspend  the  task  before  the  interrupt  is  dismissed, 
otherwise  the  program  repeatedly  services  the  interrupt  unsuccessfully. 

Writing  interrupt  handlers  in  XD  Ada  requires  detailed  knowledge  of 
the  behavior  of  the  target  computer's  interrupt  system.  It  is  not  possible 
simply  to  place  a  use  clause  on  an  entry  to  achieve  the  desired  effect. 

Normal  Ada  interrupt  entries  cause  a  tasking  reschedule  each  time  an 
interrupt  occurs.  This  inevitably  incurs  a  performance  overhead,  and 
may  mean  that  interrupts  are  not  serviced  quickly  enough.  In  order  to 
avoid  this  problem,  XD  Ada  supplies  pragma  DKECT_ INTERRUPT. 
ENTRY,  which  causes  the  interrupt  entry  to  be  connected  directly  to 
the  required  interrupt  vector.  This  run-time  efficiency  greatly  improves 
response  times.  The  form  of  this  pragma  is  as  follows: 

prmgmm  DIRJSCT_INTERRUPT_ENTRY(  interrupt.entry ) ; 

Pragma  DIRECT.INTERRUPT.ENTRY  may  be  used  where  the  pro¬ 
gram  adheres  to  one  of  two  supported  code  models.  In  fact,  most 
applications  will  naturally  adhere  to  one  or  other  of  the  models,  so  the 
practical  restrictions  from  this  requirement  are  minimal.  The  use  of 
pragma  DIRECT_INTERRUPT_ENTRY  must  meet  certain  semantic  con¬ 
ditions.  These,  along  with  the  checks  carried  out  by  the  compiler  and 
run-time  system,  are  described  in  full  in  the  XD  Ada  MC68020  Run-Time 
Reference  fkanual  part  of  this  manual. 
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Note  that  it  is  essential  that  the  lowest  level  direct  interrupt  (or  interrupt 
procedure)  is  always  higher  than  the  highest  level  normal  interrupt,  in 
order  that  the  direct  interrupt  context  is  not  left  as  a  result  of  interruptive 
preemption. 

The  models  and  the  related  conditions  are  described  in  full,  and  exam¬ 
ples  of  the  models  in  use  are  given,  in  the  XD  Ada  MC68020  Run-Time 
Reference  Manual  part  of  this  manual. 

Interrupt  procedures  and  Package  INTERRUPT_SUPPORT  are  also 
described  in  the  XD  Ada  MC68020  Run-Time  Reference  Manual  part  of  this 
mwual. 
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Supplementary  XD  Ada  information  is  provided  for  Sections  13.1,  13.2, 
13.3,  13.4,  13.5,  13.5.1,  13.7,  13.7.1,  13.7.2,  13.7.3,  13.8,  13.9,  13.10.1 
and  13.10.2.  Two  additional  sections.  Section  13.7a  and  Section  13.9a, 
provide  XD  Ada  information  on  the  package  SYSTEM  and  on  the  XD 
Ada  import  and  export  pragmas. 


13.1  Representation  Clauses 

The  following  information  supplements  paragraphs  4  and  8: 

In  XD  Ada,  an  address  clause  can  only  apply  to  a  variable  or  a  single 
entry;  an  address  clause  cannot  apply  to  a  constant,  subprogram, 
package,  or  task  unit.  See  Section  13.5  for  further  explanation. 

The  following  information  supplements  paragraph  13: 

Pragma  PACK  is  implemented  in  XD  Ada.  As  the  behavior  of  pragma 
PACK  is  implementation  dependent,  users  are  advised  to  use  represen¬ 
tation  clauses  to  ensure  a  particular  representation  across  targets. 

In  XD  Ada,  all  array  and  record  components  are  aligned  on  byte 
boundaries  by  default;  the  effect  of  pragma  PACK  on  a  record  or 
array  is  to  cause  those  components  that  are  packable  to  be  allocated  in 
adjacent  bits  without  regard  to  byte  boundaries.  Whether  any  particular 
component  is  packable  depends  on  the  rules  for  its  type;  the  XD 
Ada  MC68020  Run-Time  Reference  Manual  gives  information  on  which 
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types  can  be  packed  as  components  of  composite  types,  as  well  as 
information  on  how  these  types  are  packed. 

A  record  component  that  begins  a  variant  is  always  allocated  at  the  next 
byte  boundary;  a  variant  that  begins  on  other  than  a  byte  boundary  can 
be  obtained  only  with  a  record  representation  clause. 

XD  Ada  provides  no  additional  representation  pragmas. 

The  following  information  supplements  paragraph  14: 

XD  Ada  does  not  allow  a  representation  clause  for  a  type  that  depends 
on  a  generic  formal  type.  A  type  depends  on  a  generic  formal  tj^e 
if  it  has  a  subcomponent  of  a  generic  formal  type  or  a  subcomponent 
that  depends  on  a  generic  formal  type,  or  if  it  is  derived  from  a  generic 
formal  type  or  a  type  that  depends  on  a  generic  formal  type. 


13.2  Length  Clauses 

The  following  information  supplements  paragraph  6: 

In  XD  Ada,  for  a  discrete  type,  the  given  size  must  not  exceed  32 
(bits).  The  given  size  becomes  the  default  allocation  for  all  objects  and 
components  (in  arrays  and  records)  of  that  type.  However,  sizes  of 
objects  may  be  increased  by  the  compiler  for  optimization  purposes. 

For  integer  and  enumeration  types,  the  given  size  affects  the  internal 
representation  as  follows;  for  integer  types,  high  order  bits  are  sign- 
extended;  for  enumeration  types,  the  high  order  bits  may  be  either 
zero-  or  sign-extended  depending  upon  the  base  representation  that 
is  selected.  For  all  other  types,  the  given  size  must  equal  the  size  that 
would  apply  in  the  absence  of  a  size  specification. 

The  following  information  supplements  paragraph  8: 

The  specification  of  a  collection  size  is  interpreted  as  follows.  If  the 
value  of  the  expression  is  greater  than  or  equal  to  zero,  the  specified 
size  (representing  the  number  of  bytes  in  the  collection)  is  rounded  up 
to  the  longword  boundary  nearest  (4  bytes),  and  is  then  used  as  the 
initial  size  of  the  collection;  the  collection  is  not  extended  should  that 
initial  allocation  be  exhausted.  In  the  absence  of  a  T'STORAGE_SIZE, 
no  storage  is  initially  allocated  for  the  collection;  storage  is  allocated 
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from  the  heap  as  needed,  until  all  heap  memory  is  exhausted.  If  the 
value  is  less  than  zero,  the  exception  CONSTRAINT_ERROR  is  raised. 

The  following  information  supplements  paragraph  10: 

A  task  storage  specification  overrides  the  default  task  storage  size.  The 
specification  is  interpreted  as  follows.  If  the  value  of  the  expression 
is  greater  than  zero,  the  specified  size  is  rounded  up  to  the  nearest 
longword  boundary  (4  bytes),  and  this  determines  the  number  of 
storage  units  (b3des)  to  be  allocated  for  an  activation  of  the  task  of  the 
given  type.  In  the  absence  of  a  T'STORAGE.SIZE,  a  default  allocation 
is  used.  If  the  value  is  less  than  zero,  the  exception  CONSTRAINT_ 
ERROR  is  raised. 

The  following  information  supplements  paragraphs  8  and  10: 

NOTE 

The  XD  Ada  MC68020  Run-Time  Reference  Manual  discusses 
task  and  access  type  storage  and  storage  allocation  in  more 
detail. 

The  following  information  supplements  paragraph  12: 

In  XD  Ada,  arbitrary  values  of  small  are  accepted.  The  default  value  of 
small  is  the  largest  power  of  two  that  is  not  greater  than  the  given  delta 
(see  Section  3.5.9). 

If  small  is  specified  (see  Section  3.5.9  (LRM)),  the  specified  value  must 
not  exceed  the  default.  For  example: 

for  MY_F1XED' SMALL  ttM  0.001; 

This  example  is  a  legal  specification  for  the  declaration  of  MY.FIXED 
because  the  value  specified  for  small  (0.001)  is  less  than  the  delta  (0.1) 
and  that  also  satisfies  the  specified  range  (0.0..  1.0). 


13.3  Enumeration  Representation  Clauses 

The  following  information  supplements  paragraph  4: 

In  XD  Ada,  the  only  specific  restriction  on  enumeration  representation 
clauses  is  that  each  expression  for  an  integer  code  must  have  a  value  in 
the  range  MIN_INT  ..  MAX_INT. 
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The  following  information  supplements  paragraph  4; 

For  statically  allocated  objects  and  for  objects  allocated  from  a  collectiorr 
in  XD  Ada,  the  simple  expression  in  an  alignment  clause  must  be 
a  power  of  two.  The  upper  limit  is  2^'.  The  alignment  then  occurs 
at  a  location  that  is  a  number  of  bytes  times  the  value  of  the  simple 
expression:  a  value  of  2  causes  word  alignment,  a  value  of  4  causes 
longword  alignment,  and  so  on. 

Further  restrictions  apply  for  objects  declared  within  a  subprogram, 
where  XD  Ada  restricts  the  alignment  to  mod  1.  In  other  words,  stack- 
allocated  objects  can  only  be  byte  aligned. 

Bit-alignable  representation  clauses  are  provided  for  discrete  types, 
arrays  of  discrete  types,  and  record  types. 

See  the  XD  Ada  MC68020  Run-Time  Reference  Manual  for  information  on 
how  objects  are  allocated. 

The  following  information  supplements  paragraph  5: 

A  component  clause  specifies  the  storage  place  of  a  component  relative 
to  the  start  of  the  record.  In  XD  Ada  for  MC68020  targets,  the  size  of  a 
storage  urut  (SYSTEM. STORAGE_UNIT)  is  eight  bits  (one  byte).  If  the 
number  of  bits  specified  by  the  range  is  sufficient  for  the  component 
subtype,  the  requested  size  and  placement  of  the  field  is  observed  (and 
overlaps  storage  boundaries  if  necessary);  otherwise,  the  specification  is 
illegal.  For  a  component  of  a  discrete  t^e,  the  number  of  bits  must  not 
exceed  32;  for  a  component  of  any  other  type,  the  size  must  not  exceed 
the  actual  size  of  the  component.  See  the  XD  Ada  MC68020  Run-Time 
Reference  Manual  for  information  about  determining  the  number  of  bits 
that  are  sufficient  for  any  given  subtype. 

Component  values  in  XD  Ada  are  biased  when  a  component  clause 
requires  a  very  small  component  storage  space;  each  value  stored 
is  the  unsigned  quantity  formed  by  subtracting  COMPONENT. 
SUBTYPE 'FIRST  from  the  original  value.  See  the  XD  Ada  MC68020 
Run-Time  Reference  Manual  for  more  detailed  information. 

Component  clauses  in  XD  Ada  are  restricted  as  follows.  Any  com¬ 
ponent  that  is  not  packable  must  be  allocated  on  a  byte  boundary. 
Components  that  are  packable  can  be  allocated  without  restriction.  See 
the  XD  Ada  MC68020  Run-Time  Reference  Manual  for  a  definition  and 
description  of  packable  components. 


13-4 


Record  Representation  Clauses  13.4 


The  following  information  supplements  paragraph  6: 

Components  named  in  a  component  clause  are  allocated  first;  then, 
unnamed  components  are  allocated  in  the  order  in  which  they  are 
written  in  the  record  type  declaration.  Variants  can  be  overlapped.  If 
pragma  PACK  is  specified,  packed  allocation  rules  (see  Section  13.1) 
are  used;  otherwise,  unpacked  allocation  is  used. 

The  following  information  supplements  paragraph  8: 

XD  Ada  generates  no  implementation-dependent  components  or 
names. 

The  following  information  supplements  the  Notes  section: 

The  example  of  record  representation  and  address  clauses  in  the 
Reference  Manual  for  the  Ada  Programming  Language  is  not  relevant  for 
XD  Ada  as  it  assumes  that  type  ADDRESS  is  represented  in  24  bits, 
whereas  in  XD  Ada  type  ADDRESS  is  represented  in  32  bits.  The 
following  example  is  appropriate  to  XD  Ada: 

Example: 

trp«  CONDITION_CODE  la  ( X, N, Z, V, C ) ; 

typa  CONDI TION_CODBS  la  array  ( CONDITION_CODE )  of  BOOLEAN; 
pragu  PACK  (CONDITION_CODBS ) ; 

typa  PROGRAM_STATUS_WORD  la 

raeerd 


TRACE_ENABLE 

:  INTEGER  raaga  0  . 

.  3; 

SOPERV I SOR_STATE 

:  BOOLEAN; 

I NTERRUPT_iTATE 

:  BOOLEAN; 

INTERRUPT^MASK 

:  INTEGER  raaga  0  . 

.  7; 

CC 

1  CONDITION_CODES; 

end  racord; 

for  PROGRAM_STATUS_l»ORD  uaa 
raeord  at  tnod  1; 

TRACB.BNABLE  at  0  raapa  0 

SUPBRVISOR_STATB  at  0  raB«a  2 

INTERRUPT_i'rATB  at  0  raaga  3 

INTERRUPT_MASK  at  0  raaga  5 

CC  at  0  raaga  11 

aad  raeord; 

tot  PROGRAM_STATUS_HORD'SIZE  uaa  2  *  SYSTEM. STORAGE_UNIT; 

Note  on  the  example: 

The  record  representation  clause  defines  the  record  layout.  The  length 
clause  guarantees  that  exactly  two  storage  units  are  used. 
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Component  Specification  Example: 


■ubtyp*  S  la  INTEGER  rang*  10 

typa  REG  la 
racerd 
X  :  S; 

Y  s  S; 
and  racard; 


for  REG  uaa 
raeord 

X  at  0  raaya  0  . .  3 ; 


Y  at  0  raaga  4  . .  4 ; 


aad  racerd; 


13; 


legal  because  4  bits 
are  sufficient 
illegal  because  1  bit  is 
not  enough  to  represent 
an  integer  of  subtype  S 


Notes  on  the  example: 

The  subtype  declaration  in  this  example  implies  an  integer  with  a  min¬ 
imum  size  of  four  bits.  However,  the  components  X  and  Y  of  subtype 
S  are  biased  and  can  be  stored  in  only  two  bits.  The  component  clause 
for  X  is  legal  because  it  requires  at  least  the  minimum  number  of  bits 
required  for  the  integer  subtype;  the  component  clause  for  Y  is  illegal 
because  it  does  not  allow  enough  bits  to  represent  the  integer  subtype. 


13.5  Address  Clauses 

The  following  information  supplements  paragraph  7: 

Like  VAX  Ada,  XD  Ada  supports  address  clauses. 

In  XD  Ada,  the  simple  name  must  be  the  name  of  a  variable.  XD  Ada 
does  not  allow  address  clauses  that  name  constants;  or  subprogram, 
package,  or  task  units. 

An  intermediate  pointer  is  created  only  if  the  resulting  address  is  not  a 
compile-time  constant. 

The  placement  of  an  address  clause  in  XD  Ada  must  follow  the  rules 
given  in  Section  13.1.  In  other  words,  the  clause  and  the  variable 
declaration  must  both  occur  immediately  within  the  same  declarative 
part  or  package  specification,  and  the  declaration  must  occur  before 
the  clause.  The  restrictions  for  forcing  occurrences  also  apply;  with 
respect  to  address  clauses,  any  occurrence  of  the  variable  name  after  its 
declaration  is  a  forcing  occurrence. 
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Address  clauses  are  not  allowed  in  combination  with  any  of  the  XD  Ada 
pragmas  for  importing  or  exporting  objects.  If  used  in  such  cases,  the 
pragma  involved  is  ignored. 

The  following  information  supplements  the  Notes  section: 

Also,  if  an  address  clause  is  specified  for  an  object  of  a  type  that  has 
been  declared  with  an  alignment  clause,  the  alignment  required  for  the 
address  is  checked  against  the  alignment  given  for  the  record  type.  If 
the  two  are  incompatible,  the  exception  PROGRAM_ERROR  is  raised. 

The  same  check  applies  to  a  type  that  contains  a  component  of  a  type 
that  has  been  declared  with  an  alignment  clause  (the  alignment  of  the 
component  forces  the  alignment  of  the  containing  type). 


13.5.1  Interrupts 

The  following  information  supplements  all  of  this  section: 

Unlike  VAX  Ada,  XD  Ada  supports  interrupts.  The  address  in  the  use 
clause  is  the  address  of  the  interrupt.  The  address  is  interpreted  as  an 
offset  from  the  vector  base  register. 

XD  Ada  provides  the  additional  pragma  LEVEL.  This  pragma  is  given 
for  a  task  type,  or  single  task  of  anonymous  type,  and  gives  the  level  for 
its  interrupts. 

There  are  two  ways  an  interrupt  entry  can  be  handled,  according  to 
whether  or  not  the  task  has  a  pragma  LEVEL.  The  XD  Ada  MC68020 
Run-Time  Reference  Manual  gives  examples  of  interrupt  handlers. 

Tasks  with  interrupt  entries  but  no  pragma  run  at  interrupt  level  whilst 
accepting  an  interrupt  in  a  rendezvous.  Other  interrupts  of  the  same 
level  or  lower  levels  are  iirhibited.  It  is  possible  to  lose  interrupts  with 
this  method. 

Tasks  with  interrupt  entries  and  a  pragma  LEVEL  always  run  at  interrupt 
level,  whether  inside  or  outside  a  rendezvous.  This  enables  the  user  to 
avoid  losing  interrupts. 

An  interrupt  entry  to  a  task  with  the  pragma  behaves  like  an  ordinary 
entry  call.  An  interrupt  entry  to  a  task  with  no  pragma  behaves  like  a 
conditional  entry  call.  If  there  is  an  accept  statement  waiting  for  the 
interrupt,  the  body  of  the  accept  statement  is  executed  iirunediately. 
When  the  body  is  complete,  the  task  is  inserted  in  the  ready  queue 
and  the  interrupt  completed  by  a  retum-from-interrupt  instruction.  The 
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accept  statement  can  make  excursions  into  other  routines,  and  can  even 
make  entry  calls,  but  must  not  suspend  the  task  before  the  interrupt 
is  dismissed,  otherwise  the  program  repeatedly  services  the  interrupt 
unsuccessfully. 

Writing  interrupt  handlers  in  XD  Ada  requires  detailed  knowledge  of 
the  behavior  of  the  target  computer's  interrupt  system.  It  is  not  possible 
simply  to  place  a  use  clause  on  an  entry  to  achieve  the  desired  effect. 


13.7  The  Package  System 

The  following  information  supplements  paragraph  1: 

XD  Ada  additions  to  the  package  SYSTEM  are  described  in  Section 
13.7a. 

The  following  information  supplements  paragraph  5: 

In  XD  Ada,  the  enumeration  literal  for  SYSTEM_NAME  is  MC68020. 
The  following  information  supplements  paragraph  7: 

In  XD  Ada,  the  value  given  for  STORAGE_UNIT  must  be  8  (bits). 

The  following  information  supplements  paragraph  9: 

In  XD  Ada,  the  number  given  for  MEMORY_SIZE  must  be  2‘»31-1. 
Like  VAX  Ada,  XD  Ada  does  not  provide  support  for  checking  or 
ensuring  that  the  given  size  is  not  exceeded. 

The  following  information  supplements  paragraph  11: 

As  with  VAX  Ada,  XD  Ada  imposes  no  further  limitations  on  these 
pragmas.  To  reduce  the  amount  of  recompilation  required,  XD  Ada 
identifies  those  units  that  have  a  real  dependence  on  the  values  affected 
by  these  pragmas;  only  such  units  must  be  recompiled.  In  particular, 
predefined  XD  Ada  packages  do  not  depend  on  the  values  affected  by 
these  pragmas,  and  none  require  recompilation  if  these  pragmas  are 
used. 


1 3.7a  XD  Ada  Additions  to  the  Package  SYSTEM 

In  addition  to  the  language-required  declarations  in  package  SYSTEM, 
XD  Ada  declares  the  operations,  constants,  types,  and  subtypes  de¬ 
scribed  in  the  following  sections. 
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13.7a. 1  Properties  of  the  Type  ADDRESS 

In  XD  Ada,  ADDRESS  is  a  private  type  for  which  the  following  opera¬ 
tions  are  declared; 

Address  type 

type  ADDRESS  Is  private; 


ADDRESS_ZBRO  i  eoBStaat  ADDRESS; 

type  ADDRESS_INT  la  range  HIN_IN7  ..  MAX_INT; 

(aaetlea  TO_ADDRESS  (X  :  ADDRESS_INT)  retara  ADDRESS; 

(aaetlea  TO_ADDRESS  (X  :  {unlversal_integer } ;  retara  ADDRESS; 

fnaetlea  TO_ADDRESS_INT  (X  i  ADDRESS)  retara  ADDRESS_INT; 


faaetlea  '*•  (LEFT  :  ADDRESS;  RIGHT  ;  ADDRESS_INT)  retara  ADDRESS; 

faaetlea  '-f  (LEFT  i  ADDRESS_INT;  RIGHT  i  ADDRESsT  retara  ADDRESS; 

faaetlea  (LEFT  t  ADDRESS;  RIGHT  :  ADDRESS)  retara  ADDRESS_INT; 

faaetlea  (LEFT  i  ADDRESS;  RIGHT  i  ADDRESS_IHT)  retara  ADDRESS? 

—  faaetlea  ’>■  (LEFT,  RIGHT  :  ADDRESS)  ratnra  BOOLEAN; 

—  faaetlea  */-'  (LEFT,  RIGHT  :  ADDRESS)  retara  BOOLEAN; 

faaetlea  -<*  (LEFT,  RIGHT  >  ADDRESS)  retara  BOOLEAN; 

faaetlea  *<--  (LEFT,  RIGHT  t  ADDRESS)  ratnra  BOOLEAN; 

faaetlea  *>'  (LEFT,  RIGHT  i  ADDRESS)  ratura  BOOLEAN; 

fnaetlea  ’>-*  (LEFT,  RIGHT  :  ADDRESS)  retara  BOOLEAN; 

—  Note  that  because  ADDRESS  is  a  private  type 

the  functions  and  ■/-■  are  already  available 

--  Generic  functions  used  to  access  memory 

geaerle 

typo  TARGET  Is  private; 

fnaetlea  FETCH_FROH_ADORESS  (A  i  ADDRESS)  ratnra  TARGET; 

geaerle 

type  TARGET  la  private; 

preeedaro  ASSIGN_TO_AODRESS  (A  :  ADDRESS;  T  ;  TARGET); 

The  addition,  subtraction,  and  relational  functions  provide  arithmetic 
and  comparative  operations  for  addresses.  The  generic  subprograms 
FETCH_FROM_ADDRESS  and  ASSIGN.TO. ADDRESS  provide  op¬ 
erations  for  reading  from  or  writing  to  a  given  address  interpreted  as 
having  any  desired  type.  ADDRESS.ZERO  is  a  deferred  constant  whose 
value  corresponds  to  the  first  (machine)  address. 
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In  an  instantiation  of  FETCH_FROM_ ADDRESS  or  ASSlGN_TO_ 
ADDRESS,  the  actual  subtype  corresponding  to  the  formal  type  T 
must  not  be  an  unconstrained  array  type  or  an  unconstrained  type  with 
discriminants.  If  the  actual  subtype  is  a  type  with  discriminants,  the 
value  fetched  by  a  call  of  a  function  resulting  from  an  instantiation  of 
FETCH_FROM_ADDRESS  is  checked  to  ensure  that  the  discriminants 
satisfy  the  constraints  of  the  actual  subtype.  In  any  other  case,  no  check 
is  made. 

Example: 

X  1  INTEGER; 

A  I  SYSTEM. ADDRESS  X' ADDRESS;  —  legal 

fuBCtioa  FETCH  la  aaw  FETCH_FROM_ADDRESS{ INTEGER) ; 
procedure  ASSIGN  ie  aew  ASSIGN_To2aDDRBSS( INTEGER) ; 

X  !-  FETCH(A);  —  li)te  "X  i-  A.all;- 

ASSIGN(A,X);  —  li)ce  ’A. all  i-  X;- 


13.7a.2  Type  Class  Enumeration  Type 

XD  Ada  declares  the  following  enumeration  type  for  identifying  the 
various  Ada  type  classes: 

type  TYPE_CLASS  la  (TYPE_CLASS_ENUMERATION, 

type~class2integer, 
type~class”fixed_point , 
TYPE~CLASS_FLOATING_POINT , 

type_class2array , 
type'class^record , 
type'’class~access  , 
typeIclass'task, 

TYPB_CLASS_ADDRESS ) ; 

In  addition  to  the  usual  operations  for  discrete  types  (see  Section  3.5.5), 
XD  Ada  provides  the  attribute  TYPE.CLASS. 

For  every  type  or  subt3rpe  T: 

T'TYPE.CLASS  Yields  the  value  of  the  type  class  for  the  full  type  of 
T.  If  T  is  a  generic  formal  type,  then  the  value  is  that 
for  the  corresponding  actual  subtype.  The  value  of 
this  attribute  is  of  the  type  TYPE_CLASS. 

This  attribute  is  only  allowed  if  its  unit  names  the  predefined  package 
SYSTEM  in  a  with  clause. 
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Examples: 

Given 


typ*  MY_INT  la  raaga  1..10; 
typa  NBW_INT  la  aaw  STRING; 
paekaga  PACK  la 

trpa  PRIV  la  prlvata; 
prlvata 

typa  PRIV  la  aaw  FLOAT; 
aad  PACK; 

then 

—  MY_INT'TYPE_CLASS  equals  TYPE_CLASS_ INTEGER 

—  NEW_INT'TYPi_CLASS  equals  TYPE^CLASS'aRRAY 

—  PRIV'TYPE_CLASS  equals  TYPB”cLASS~rLOATING_POINT 


13.7a.3  Hardware-Oriented  Types  and  Functions 

XD  Ada  declares  the  following  types,  subtypes,  amd  functions  for 
convenience  in  working  with  MC68020  hardware-oriented  storage: 


XD  Ada  hardware-oriented  types  and  functions 

type  BIT_ARRAY  la  array  (INTEGER  raaga  <>)  of  BOOLEAN; 
prmgmm  PACK ( B I T_ ARRAY ) ; 

aabtypa  BIT_ARRAY_8  la  BIT_ARRAY  (0  ..  7); 

aabtypa  BIT^ARRAY^ie  la  BIT_ARRAY  (0  ..  IS); 
aabtypa  BIT~ARRAY~32  la  BIT^ARRAY  (0  ..  31); 
aabtypa  BlT^AHHAy'ei  la  BIT~ARRAY  (0  ..  63); 
type  UNSiGNiD_BYTi  la  raaga  0  ..  255; 

(ar  UNSIgned^BYTB'SIZB  uaa  8; 

faaetlaa  ’not*  (LBFT  t  UNSIGNED_BYTE)  ratara  0NSI6NBD_BYTB; 

(aaatlaa  "and*  (LBFT,  RIGHT  t  tmSIGNED~BYTE)  ratara  UNSIGNBd'byTB; 

taaetlea  -or*  (LBFT,  RIGHT  i  UNSIGNBD_BYTE )  ratara  UNSIGNBd'bYTB; 

(aaatlaa  *xor'  (LBFT,  RIGHT  t  UNSIGNBD.BYTB)  ratara  UNSI6NBD~BYTB; 

(aaatlaa  T0_UNSIGHBD_BYTE  (X  :  BIT_ARRAY_8)  ratara  UNSIGNBD_BYTB; 
(aaatlaa  To”biT_ARRAY_8  (X  j  UNSlGNED_BYiE)  ratara  BIT_ARRAY_8; 

typa  UNSIGNBD_BYTB.ARRAY  la  array  (INTEGER  raaga  <>)  e(  UNSIGNED_BYTE; 
typa  UNSIGNBD^hORO*  la  raaga  0  ..  65535; 

(ar  UNSIGNBd'hORO'SIZE  aaa  16; 

(aaatlaa  "not"  (LEFT  i  UNSIGNED_W0RD) 

(aaatlaa  'and'  (LBFT,  RIGHT  :  UNSIGNEd”h0RD) 

(aaatlaa  "or"  (LEFT,  RIGHT  :  UNSIGNED_WORD) 

(aaatlaa  ‘xor’  (LBFT,  RIGHT  t  UNSIGNED_HORD) 

(aaatlaa  Tu_UNSIGNED_WORD  (X  «  BIT_ARRAY_16 ) 

(aaatlaa  T0~BIT_ARRAY_16  (X  :  0NS1GNED_W0RD) 
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ratara  UNSIGNBD_NORO; 
ratara  UNSIGNED~MORD; 
ratara  UNSIGNBD~WORD; 
ratara  UNSIGNED~NORO; 

ratara  UNSIGNED_wORD; 
ratara  BIT_ARRAY_16 ; 


typ«  UNSIGNED_W0RD_ARRAY  la  array  (INTEGER  raaga  <>)  ol  UNSIGNED_W0RD; 


typa  UNSIGNED_LONGWORD  la  raBQa  MIN_INT  ..  MAX_INT; 
for  UNSIGNED_LONGWORD'SIZE  uaa  32; 

fuaetlon  ’not"  (LEFT  :  UNSIGNED_LONGWORD )  ratura  UNSIGNED_LOHGWORD; 

fuaetloB  'and'  (LEFT,  RIGHT  :  UNS1GNED_L0NGW0RD )  ratura  UNSIGNED^LONGWORD ; 

fuaetloB  -or"  (LEFT,  RIGHT  :  UNS1GNED_L0NGW0RD )  ratura  UNSIGNEd'lONGWORD; 

fuaetlea  "xor"  (LEFT,  RIGHT  :  UNS1GNED~L0NGW0RD)  ratura  UNSIGNED_LONGWORD; 

fuactloB  TO_UNSIGNED_LONGWORD  (X  :  BIT_ARRAY_32 )  ratura  UNSIGNED_LONGWORD: 
fnaetioa  TO_BIT_ARRAY_32  (X  :  UNSIGNED_WORD )  ratura  BIT_ARRAY_327 

typa  UNSIGNBD_LONGWORD_ARRAY  la  array  (INTEGER  raB«a  <>)  of  UNSIGNED_LONGWORD; 


13.7a. 4  Conventional  Names  for  Unsigned  Longwords 

The  following  XD  Ada  declarations  provide  conventional  names  for 
static  subtypes  of  the  predefined  type  UNSIGNED. LONGWORD: 


aubtypa 

UNSIGNED. 

1 

la 

UNSIGNED. 

LONGWORD 

0 

.  2* 

1-1 

aubtypa 

UNSIGNED^ 

2 

la 

UNSIGNED. 

LONGWORD 

0 

.  2* 

2-1 

aubtypa 

UNSIGNED^ 

3 

la 

unsigned] 

LONGWORD 

rsAfs 

0 

.  2* 

3-1 

aabtypo 

UNSIGNED^ 

4 

la 

unsigned] 

LONGWORD 

0 

.  2* 

4-1 

aabtypa 

UNSIGNED^ 

5 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

5-1 

aubtypa 

UNSIGNED^ 

6 

la 

unsigned] 

LONGWORD 

rang* 

0 

.  2* 

6-1 

aabtypo 

UNSIGNED^ 

7 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

7-1 

aabtypa 

UNSIGNED^ 

8 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

.  2* 

8-1 

aabtypo 

UNSIGNED^ 

9 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

9-1 

aabtypo 

UNSIGNED^ 

10 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

10-1 

aabtypo 

UNSIGNED^ 

11 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

11-1 

aabtypa 

unsigned]] 

12 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

12-1 

aabtypo 

unsigned]] 

13 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2« 

13-1 

aabtypa 

UNSIGNED^ 

14 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

14-1 

aubtypa 

unsigned^ 

15 

lo 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

15-1 

aabtypa 

UNSIGNED. 

16 

la 

unsigned. 

LONGWORD 

raaga 

0 

.  2* 

16-1 

aubtypa 

UNSIGNED^ 

17 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

17-1 

ar.atypa 

UNSIGNED. 

18 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

18-1 

aabtypa 

unsigned] 

19 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2« 

19-1 

aabtypa 

unsigned] 

20 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

20-1 

aabtypa 

unsigned] 

21 

la 

UNS I GNED.LONGNORD 

raaga 

0 

.  2» 

21-1 

aabtypa 

unsigned] 

22 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

.  2* 

22-1 

aabtypa 

unsigned] 

23 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

23-1 

aabtypa 

unsigned] 

24 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

24-1 

aabtypa 

unsigned] 

25 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

25-1 

aabtypa 

unsigned] 

26 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

26-1 

aabtypa 

unsigned] 

27 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

27-1 

aabtypa 

unsigned] 

28 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

28-1 

aabtypa 

unsigned] 

29 

la 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

29-1 

aabtypa 

unsigned] 

]30 

lo 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

30-1 

oabtypa 

unsigned] 

’31 

lo 

unsigned] 

LONGWORD 

raaga 

0 

.  2* 

31-1 
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13.7.1  System-Dependent  Named  Numbers 

In  XD  Ada,  the  values  for  system-dependent  named  numbers  are  as 
shown  in  the  following  table. 


Attribute 

MC68020 

MIN.INT 

-2^' 

MAXJNT 

2’'-l 

MAX.DIGITS 

18 

MAX.MANTISSA 

31 

FINE.DELTA 

2.0"^' 

TICK 

162.5  X  10-‘ 

13.7.2  Representation  Attributes 

The  following  information  supplements  all  of  this  section: 

For  any  object,  program  unit,  label,  or  entry  X: 

X' ADDRESS  Yields  the  address  of  the  first  of  the  storage  ele¬ 

ments  allocated  to  X.  For  a  subprogram,  package, 
task  unit  or  label,  this  value  refers  to  the  machine 
code  associated  with  the  corresponding  body  or 
statement.  For  an  entry  for  which  an  address 
clause  has  been  given,  the  value  refers  to  the  offset 
of  the  interrupt  vector  from  the  vector  base  register. 
The  value  of  this  attribute  is  of  the  type  ADDRESS 
defined  in  the  package  SYSTEM. 

For  an  object  that  is  a  variable,  the  value  is  the  ac¬ 
tual  address  of  the  variable  (which  may  be  statically 
or  dynamically  allocated).  TTris  attribute  forces  a 
variable  to  be  allocated  in  memory  rather  than  in 
a  register,  and  causes  the  variable  to  be  marked  as 
volatile  for  the  duration  of  the  block  statement  or 
body  containing  use  of  the  attribute.  If  the  location 
of  the  variable  is  not  byte-aligned,  the  value  is 
the  address  of  the  lowest  byte  that  contains  the 
variable.  For  an  object  that  is  a  constant,  the  value 
is  the  address  of  the  constant  value  in  memory; 
however,  two  occurrences  of  C’ ADDRESS,  where 
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C  denotes  a  constant,  may  or  may  not  yield  the 
same  address  value.  For  an  object  that  is  a  named 
number,  the  value  is  zero  (ADDRESS_ZERO). 

NOTE 

In  the  context  of  these  representation 
attributes,  ADDRESS_ZERO  means  only 
that  no  useful  interpretation  of  a  nonzero 
value  is  currently  supported.  That  is,  its 
use  as  a  result  of  C'ADDRESS  is  subject 
to  change. 

For  an  access  object,  X.all’ADDRESS  is  the  address 
of  the  designated  object;  X.all'ADDRESS  is  subject 
to  an  ACCESS_CHECK  for  the  designated  object. 
For  a  record  component,  X.C' ADDRESS  is  subject 
to  a  DISCRIMINANT_CHECK  for  an  object  in 
a  variant  part.  For  an  array  component  or  slice, 
X{I)' ADDRESS  or  X(ll  .. 12)' ADDRESS  is  subject  to 
an  1NDEX_CHECK  for  the  denoted  component  or 
slice. 

For  program  units  that  are  task  units  or  package 
units,  the  value  is  zero  (ADDRESS_ZERO).  For 
program  units  that  are  subprograms,  the  value  is 
the  same  as  the  address  that  would  be  exported. 
(See  Section  13. 9a. 1.4  (LRM)  for  information  on 
pragmas  EXPORT  FUNCTION  and  EXPORT. 
PROCEDURE). 

For  entries,  the  value  is  zero  (ADDRESS.ZERO). 

For  labels,  the  value  is  the  address  of  the  machine 
code  which  follows  the  label. 

For  any  type  or  subtype  X,  or  for  any  object  X: 

X'SIZE  For  a  type  or  a  subtype,  the  value  is  limited  to 

values  in  the  range  6  ..  MAX.INT;  the  exception 
NUMERIC.ERROR  (see  Section  11.1)  is  raised  for 
values  outside  this  ramge.  For  an  object  that  is  a 
variable  or  a  constant  in  XD  Ada,  the  value  is  its 
size  in  bits.  For  an  object  that  is  a  named  num¬ 
ber,  the  value  is  zero.  For  a  record  component, 
X.C 'SIZE  is  subject  to  a  DISCRIMINANT.CHECK 


13-14 


Representation  Attributes  1 3.7.2 


for  an  object  in  a  variant  part.  For  an  array  compo¬ 
nent  or  slice,  X(I)'SIZE  or  X(I1..I2)'SIZE  is  subject 
to  an  INDEX_CHECK  for  the  denoted  component 
or  slice. 

For  any  type  or  subtype  X: 

X'MACHINE_SIZE  Yields  the  number  of  machine  bits  to  be  allocated 
for  variables  of  the  type  or  subtype.  This  value 
takes  into  account  any  padding  bits  used  by  XD 
Ada  when  allocating  a  variable  on  a  byte  boundary. 
The  value  of  this  attribute  is  of  the  type  umwrsal_ 
integer. 

The  value  is  always  a  multiple  of  8  (bits).  In  partic¬ 
ular,  for  discrete  types  it  is  8,  16,  or  32.  The  value 
is  limited  to  the  range  O..MAX_INT;  the  exception 
NUMERIC_ERROR  is  raised  for  values  outside  this 
range. 

For  any  object  X: 

X '  BIT  Yields  the  bit  offset  within  the  storage  unit  (byte) 

that  contains  the  first  bit  of  the  storage  allocated  for 
the  object.  The  value  of  this  attribute  is  of  the  type 
universaljnteger,  and  is  always  in  the  range  0..7. 

For  an  object  that  is  a  variable  or  a  constant  al¬ 
located  in  a  register,  the  value  is  zero.  (The  use 
of  this  attribute  does  not  force  the  allocation  of 
a  variable  to  memory.)  For  an  object  that  is  a 
formal  parameter,  this  attribute  applies  either 
to  the  matching  actual  parameter  or  to  a  copy 
of  the  matching  actual  parameter.  For  an  ac¬ 
cess  object,  the  value  is  zero  (in  the  absence  of 
CONSTRAINT.ERROR);  X.all'BIT  is  subject  to 
an  ACCESS.CHECK  for  the  designated  object. 

For  a  record  component,  X.C'BIT  is  subject  to 
a  DISCRIMINANT_CHECK  for  a  component  in 
a  variant  part.  For  an  array  component  or  slice, 
X(I)'BIT  or  Xai..I2)'BIT  is  subject  to  an  INDEX. 
CHECK  for  the  denoted  component  or  slice. 
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The  following  information  supplements  the  Notes  section: 

The  attribute  X'MACHINE_S1ZE  gives  the  size  that  would  be  used  for 
a  variable  of  the  type  or  subtype;  it  does  not  give  the  size  that  may  be 
used  for  a  component  of  that  type  or  subtype. 

The  machine  size  of  a  type  or  subtype  can  be  influenced  by  representa¬ 
tion  clauses,  unlike  the  size  of  a  type  or  subtype,  which  is  independent 
of  representation  clauses.  The  machine  size  of  a  base  type  can  be  less 
than,  equal  to,  or  greater  than  the  size  of  that  same  base  type.  See  the 
XD  Ada  MC68020  Run-Time  Reference  Manual  for  examples  and  additional 
discussion. 


13.7.3  Representation  Attributes  of  Real  Types 

The  following  information  supplements  paragraphs  3  and  4: 

For  both  fixed-  and  floating-point  types: 

T'MACHINE.ROUNDS  In  XD  Ada  this  value  is  FALSE 

T'MACHINE.OVERFLOWS  In  XD  Ada  this  value  is  FALSE 

The  XD  Ada  values  of  the  other  representation  attributes  for  floating¬ 
point  types  are  dependent  on  the  floating-point  type  and  are  listed  in 
Appendbc  F. 


13.8  Machine  Code  Insertions 

The  following  information  supplements  paragraph  4: 

XD  Ada  provides  the  package  MACHINE.CODE.  Machine  code  inser¬ 
tions  can  be  expanded  in  line. 

This  predefined  package  and  not  a  user-defined  package  must  be 
named  in  a  with  clause  that  applies  to  the  compilation  unit  in  which  the 
code  statement  ocaus. 

The  following  is  an  example  of  MACHINE_CODE  and  the  with  clause 
in  use: 
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—  A  machine  code  procedure  to  evaluate  the  sine  and  cosine  of 

—  pareuneter  X,  returning  the  results  in  parameters  Y  and  Z 

—  respectively;  the  procedure  is  to  be  expanded  in  line,  so 

—  it  does  not  require  a  stack  frame  of  its  owni 
with  MACHINE_CODE; 

procedure  SINCOSl  (  X:  la  FLOAT; 

Y!  out  FLOAT; 


Z:  out  FLOAT  ) 
uuo  MACHINE.CODE; 
FSINCOS_REG_INST'  ( 

is 

OPCODE 

■> 

FSINCOS 

SOURCE.REGISTER 

■  > 

FPO, 

SIN_REGISTER 

»> 

FPl, 

cos'register 

■> 

FP2  ) ; 

sad  SINCOSl; 

XD  Ada  provides  the  pragma  CALL_SEQUENCE_PROCEDURE  which 
specifies  parameter-passing  mechanisms  for  machine  code  procedures, 
lire  pragma  is  defined  in  Appendix  B.  Examples  of  machine  code 
insertion  are  given  in  Section  6.1  of  the  XD  Ada  MC68020  Run-Time 
Reference  Manual.  For  the  specification  of  the  package  MACHINE. 
CODE,  see  Appendix  B  of  the  XD  Ada  MC68020  Run-Time  Reference 
Manual. 


1 3.9  Interface  to  Other  Languages 

The  following  information  supplements  paragraph  4: 

As  with  VAX  Ada,  use  of  pragma  INTERFACE  in  XD  Ada  is  interpreted 
as  being  equivalent  to  supplying  the  body  of  the  named  subprogram  or 
subprograms.  Therefore,  ^e  following  rules  apply: 

•  If  a  subprogram  body  is  given  later  for  a  subprogram  named  with 
pragma  INTERFACE,  the  body  is  illegal. 

•  If  pragma  INTERFACE  names  a  subprogram  body,  the  pragma  is 
illegal. 

•  If  a  duplicate  pragma  INTERFACE  is  given,  the  latter  pragma  is 
illegal. 

In  XD  Ada,  pragma  INTERFACE  applies  to  a  renaming  only  if  the 
renaming  occurs  in  the  same  declarative  part  or  package  specification 
as  the  pragma.  The  renamed  subprogram  must  dso  occur  in  that  same 
declarative  part  or  package  specification;  renamed  subprograms  that 
occur  outside  the  declarative  part  or  package  specification  are  ignored 
(without  a  warning  diagnostic). 
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In  addition,  XD  Ada  interprets  the  effect  of  pragma  INTERFACE  in  such 
a  way  that  it  accepts  and  ignores  implicit  declarations  of  subprograms 
(such  as  predefined  operators  derived  subprograms,  attribute  functions, 
and  so  on). 

Dependent  upon  its  use  in  an  XD  Ada  program,  pragma  INTERFACE  is 
interpreted  in  combination  with  one  of  two  XD  Ada  import  subprogram 
pragmas:  IMPORT.FUNCTION  or  IMPORT.PROCEDURE.  These 
pragmas  are  described  in  Section  13.9a.  1. 

The  language  name  is  ignored,  and  so  may  be  any  identifier  that 
suggests  the  language,  source,  or  nature  of  the  imported  subprogram. 

If  pragma  INTERFACE  is  used  without  one  of  these  import  pragmas,  a 
default  interpretation  is  used,  as  follows: 

•  If  the  subprogram  name  applies  to  a  single  subprogram,  then  a 
default  import  pragma  is  assumed  as  follows: 

For  a  function,  the  default  is  as  follows: 

prmgmm  IMPORT_FUNCTION  < f unction_designator ) ; 

For  a  procedure,  the  default  is  as  follows; 

pragma  IMPC'’T_PROCEDORE  ( procedure_identif  ier  ) ; 

•  If  the  subprogram  name  applies  to  tw’o  or  more  subprograms,  the 
pragma  applies  to  all  of  them.  However,  a  warning  is  given  if  the 
appropriate  XD  Ada  import  pragmas  are  not  given  for  all  of  the 
subprograms. 

Whether  or  not  pragma  INTERFACE  is  used  with  an  import  pragma,  the 
subprogram  name  must  be  an  identifier,  or  a  string  literal  that  denotes 
an  operator  symbol.  In  the  following  example,  pragma  INTERFACE 
specifies  that  the  indicated  routines  SQRT  and  EXP  are  to  be  imported 
and  used  as  bodies  for  the  XD  Ada  functions  SQRT  and  EXP  in  package 
FORT_UB; 

paehagm  FORT_LIB  la 

(uBetiea  iQRT(X  :  FLOAT)  ratun  FLOAT; 
fuBetlea  EXP(X  l  FLOAT)  ratura  FLOAT; 
prlvata 

pragma  INTERFACE; FORTRAN,  SQRT); 
pragma  INTERFACE; FORTRAN,  EXP); 
aad  FORT  LIB; 
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The  following  information  supplements  paragraph  5; 

In  XD  Ada,  the  example  package  FORT_LIB  is  interpreted  as  follows; 
pragma  INTERFACE  specifies  that  the  indicated  routines  SQRT  and 
EXP  are  to  be  imported  and  used  as  bodies  for  the  Ada  functions  SQRT 
and  EXP  in  package  FORT_LIB. 

paekaga  CHOOSE_R  la 

praeadura  P(X  :  INTEGER); 
praaadura  P(X  :  FLOAT); 

prlaata 

praeadura  R(X  <  FLOAT)  raaaaaa  P; 
pra«M  INTERFACE (ASSEMBLER,  R); 
aad  CHOOSE_R; 

In  this  example,  pragma  INTERFACE  indicates  that  the  body  for  the 
second  procedure  P  is  to  be  imported  as  routine  R. 

The  following  information  supplements  the  Notes  section: 

The  meaning  of  the  subprogram  name  is  determined  as  for  any  name 
(see  Section  8.3  (LRM)),  except  that  the  name  can  denote  more  than  one 
subprogram.  Thus,  in  the  following  declaration  the  pragnna  INTERFACE 
applies  to  the  first  two  procedures;  it  does  not  apply  to  the  third 
because  the  declaration  is  not  visible  at  the  place  of  the  pragma. 

proeadur*  P  (Bi  BOOLEAN); 
praeadura  P  (It  INTEGER); 
pragaa  INTERFACE  (ASSEMBLER,  P); 
praeadura  P  (Ft  FLOAT); 

This  same  interpretation  is  made  for  pragmas  used  to  import  and  export 
subprograms  (see  Section  13.9a. 1). 

If  pragma  INTERFACE  and  pragma  INLINE  are  used  together,  the 
pragma  INLINE  is  ignored  regardless  of  the  order  in  which  the  two 
pragmas  appear. 

Refer  to  Chapter  3  of  the  XD  Ada  MC68020  Run-Time  Reference  Manual 
for  subprogram  calling  conventions  and  run-time  organisation,  while 
Chapter  6  of  the  same  m.anual  describes  low-level  interfaces  and  assem¬ 
bly  language  modules. 
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13.9a  XD  Ada  Import  and  Export  Pragmas 


XD  Ada  provides  import  and  export  pragmas  designed  specifi¬ 
cally  for  constructing  programs  composed  of  both  Ada  and  non- 
Ada  entities.  The  import  pragmas  allow  an  Ada  program  to  refer 
—  written  in  another  language;  the  export  pragmas  make 
Ada  entities  available  to  programs  written  in  other  languages 
The  names  of  the  pragmas  indicate  the  kind  of  entity  involved- 
IMPORT.FUNCTION  and  EXPORT_FUNCTION  apply  to  nongeneric 
functions;  IMPORT.PROCEDURE  and  EXPORT  PROCEDURE  apolv  to 
nongenenc  procedures;  IMPORT.OBJECT  and  EXPORT  OBIECT  aoolv 
to  objects;  and  IMPORT.EXCEPTION  and  EXPORT.EXCEPTION  apply 
to  exceptions.  These  pragmas  are  described  in  this  section,  summarized 
in  Annex  B,  and  listed  in  Appendix  F. 

All  the  XD  Ada  import  and  export  pragmas  have  the  following  form; 

P*-*#**  iinport_export_pragma_neut>e 

( internal_name  [,  external_designator ) 

( ,  pragma_Bpecif ic_options ] ) ; 

import_export_pragma  name  i!= 


EXPORT_EXCEPTION  |  EXPORT_ FUNCTION 
I  EXPORT_OBJECT  j  EXPORT_PROCEDURE 
I  IMPORT_EXCEPTION  j  IMPORT~FUNCTION 
I  IMPORT_OBJECT  j  IMPORt"pROCBDURE 

internal_name  :j-  (INTERNAL  «>]  8imple_name 

I  (INTERNAL  -> )  operator_8ymbol  —  Can  be  used  only  for 

--  IMPORT_FUNCTION 
external_de8ignator  ii-  (EXTERNAL  ->)  external_8yinbol 
external_BymboI  i t«  identifier  (  string  literal 


The  internal  name  can  be  an  Ada  simple  name,  or,  if  the  declared  entity 
IS  a  function,  the  internal  name  can  be  a  string  literal  that  denotes  an 
^erator  symbol.  A  subprogram  to  be  imported  or  exported  must  be 
identified  by  its  internal  name  and  parameter  types;  and  in  the  case  of 
a  function,  by  the  result  type  (see  Section  13.9a.  1.1). 

The  external  designator  determines  a  symbol  that  is  referenced  or 
declared  in  the  linker  object  module.  If  an  identifier  is  given,  the 
identifier  is  used.  If  a  string  literal  is  given,  the  value  of  the  string  is 
used.  The  value  of  a  string  literal  must  be  a  symbol  that  is  acceptable 
to  the  XD  Ada  Builder;  it  need  not  be  valid  as  an  Ada  identifier  (For 
example,  the  dollar  character  ($)  can  be  used.)  If  no  external  designator 
IS  given,  the  internal  name  is  used  as  the  external  designator.  If  the 
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external  designator  (explicit  or  default)  is  longer  than  12  characters,  the 
import  or  export  pragma  is  ignored. 

Pragma-specific  options  are  described  in  the  individual  pragma  sections 
that  follow. 

The  XD  Ada  import  and  export  pragmas  are  only  allowed  at  the  place 
of  a  declarative  item,  and  must  apply  to  an  entity  declared  by  an  earlier 
declarative  item  of  the  same  declarative  part  or  package  specification. 
At  most  one  import  or  export  pragma  is  allowed  for  any  given  entity;  in 
the  case  of  multiple  overloaded  subprograms,  this  rule  applies  to  each 
subprogram  independently. 

Additional  placement  and  usage  rules  apply  for  particular  pragmas  as 
described  in  the  following  sections. 

Note: 

Argument  associations  for  XD  Ada  import  and  export  pragmas  can  be 
either  positional  or  named.  With  positional  association,  the  arguments 
are  interpreted  in  the  order  in  which  they  appear  in  the  syntax  defini¬ 
tion.  The  rules  for  the  mixing  of  positional  and  named  association  are 
the  same  as  those  that  apply  to  subprograms  (see  Section  6.4  (LRM)). 

A  pragma  for  an  entity  declared  in  a  package  specification  must  not  be 
given  in  the  package  body.  (A  pragma  for  an  entity  given  in  the  visible 
part  of  a  package  specification  can,  however,  be  given  in  either  the 
visible  or  private  part  of  the  specification.) 

No  checking  is  provided  to  ensure  that  exported  symbols  do  not  con¬ 
flict  with  each  other  or  with  other  global  symbols;  such  checking  is 
performed  by  the  XD  Ada  Builder. 


13.9a. 1  Importing  and  Exporting  Subprograms 

XD  Ada  provides  a  series  of  pragmas  that  make  it  possible  to  call 
nongeneric  subprograms  in  a  mixed-language  programming  environ¬ 
ment.  The  IMPORT.FUNCnON  and  IMPORT.PROCEDURE  pragmas 
specify  that  the  body  of  the  subprogram  associated  with  an  Ada  sub¬ 
program  specification  is  to  be  provided  from  assembly  language. 
Pragma  INTERFACE  must  precede  one  of  these  im.port  pragmas  (see 
SecHon  13.9).  The  EXPORT_FUN(rnON  and  EXPORT.PROCEDURE 
pragmas  allow  an  Ada  procedure  or  function  to  be  called  from  assem¬ 
bly  language.  The  pragmas  support  parameter  passing  by  means  of 
'egisters. 
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Importing  Subprograms 

XD  Ada  provides  two  pragmas  for  importing  subprograms; 
IMPORT.FUNCTION  and  IMPORT.PROCEDURE.  These  pragmas 
allow  the  import  of  the  kind  of  subprograms  indicated. 

The  pragmas  for  importing  subprograms  have  the  following  form: 

pragaa  I MPORT_ FUNCTION  |  IMPORT_PROCEDURe 

([  INTERNAL  =>)  internal_nanie 
[,  [EXTERNAL  => )  external_de8ignBtor  ) 

(>  ( PARAMETER_TYPES  »> )  (  parameter_typeB  )  ] 

[,  1RESULT_TYPE  -> )  type_mark  )  —  FUNCTION  only 

[,  [MECHANISM  «> )  mechanism  ) 

(,  (RESULT_MECHANISM  -> )  mechanism_8pec  )  —  FUNCTION  only 

(,  (PRESERVED  REGISTERS  ->  )  (  regi8ter8  )  ) 

)I 


paraineter_types  it- 

aull  I  type_mark  {,  type_mark) 

mechaniam  ii- 

mechanl8m_spec  |  (  mechani8m_8pec  (,  mechani8m_8pec }  ) 
mechani8m_8pec  i:- 

mechanism_name  (  (  (REGISTER  ->  )  register_name  )  J 

mechanism_name 

VALUE  I 

REFERENCE  |  BIT_REFERENCE  | 

DOPE_VECTOR  j  BIT~DOPE_VBCTOR 

registers 

anil  I  regiater_name  (,  regi8ter_name  > 

Functions  must  be  identified  by  their  internal  names  and  parameter 
and  result  types.  The  parameter  and  result  types  can  be  omitted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  types 
must  be  specified. 

Procedures  must  be  identified  by  their  internal  names  and  parameter 
types.  The  parameter  types  can  be  omitted  only  if  there  is  exactly 
one  procedure  of  that  name  in  the  same  declarative  part  or  package 
specification.  Otherwise,  the  parameter  types  must  be  specified. 

The  external  designator  denotes  an  XD  Ada  Builder  global  symbol  that 
is  associated  with  the  external  subprogram.  If  no  external  designator  is 
given,  the  internal  name  is  used  as  the  global  symbol. 
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The  parameter  types  option  specifies  a  series  of  one  or  more  type 
marks  (type  or  subtype  names),  not  parameter  names.  Each  type  mark 
is  positionally  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicated  by  the 
reserved  word  null. 

The  result  type  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 

The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine. 

Mechaiusm  names  are  described  as  follows.  Within  these  definitions, 
the  term  bit  string  means  any  one-dimensional  array  of  a  discrete  type 
whose  components  occupy  successive  single  bits.  The  term  simple 
record  type  means  a  record  type  that  does  not  have  a  variant  part  and  in 
which  any  constraint  for  each  component  and  subcomponent  is  static. 

A  simple  record  subtype  is  a  simple  record  type  or  a  static  constrained 
subtype  of  a  record  type  (with  discriminants)  in  which  any  constraint  for 
each  component  and  subcomponent  of  the  record  type  is  static. 

VALUE  Specifies  that  the  immediate  value  of  the  actual 

parameter  is  passed.  Values  of  scalars,  access 
types,  address  types  and  private  types  whose 
full  type  is  either  a  scalar,  an  access  type  or  an 
address  type  can  be  passed  by  VALUE.  If  the 
value  is  a  private  type,  the  pragma  must  occur 
after  the  full  declaration  of  the  private  type.  Bit 
strings  can  also  be  passed  by  VALUE. 

REFERENCE  Specifies  that  the  address  of  the  value  of  the 

actual  parameter  is  passed.  This  mechanism  can 
be  used  for  parameters  of  any  type. 

DOPE. VECTOR  Specifies  that  the  address  of  the  DOPE.VECTOR 

is  passed,  a  32-bit  pointer  to  an  object,  taking 
the  form  described  in  Section  2.1.4  of  the  XD 
Ada  MC68020  Run-Time  Reference  Manual. 

BIT.DOPE. VECTOR  Specifies  that  the  address  of  the  BIT.DOPE. 

VECTOR  is  passed,  a  32-bit  pointer  to  an  oWeet, 
taking  the  form  described  in  Section  2.1.4  of  the 
XD  Ada  MC68020  Run-Time  Reference  Manual. 
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If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
name  without  parentheses),  all  parameters  are  passed  using  that  mech¬ 
anism.  If  the  second  form  is  given  (a  series  of  mechanism  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  parameter  in  the  same  position  in  the  subprogram 
specification  will  be  passed.  With  the  second  form,  each  parameter 
name  must  have  an  associated  mechanism  name. 

The  result  mechanism  option  is  used  only  for  functions;  it  specifies 
the  parameter-passing  mechanism  for  passing  the  result  type,  and 
optionally,  a  specific  register  used  to  pass  the  result. 

The  preserved  registers  option  gives  a  list  of  hardware  registers  which 
are  not  altered  by  the  procedure  or  function.  If  this  option  is  omitted  it 
implies  that  no  registers  are  preserved. 

In  addition  to  the  rules  given  in  Section  13.9a,  the  rules  for  importing 
subprograms  are  as  follows; 

•  If  an  import  pragma  is  given  for  a  subprogram  specification,  pragma 
INTERFACE  (see  Section  13.9)  must  also  be  given  for  the  subpro¬ 
gram  earlier  in  the  same  declarative  part  or  package  specification. 
The  use  of  pragma  INTERFACE  implies  that  a  corresponding  body 
is  not  given. 

•  If  a  subprogram  has  been  declared  as  a  compilation  unit,  the 
pragma  is  oiUy  allowed  after  the  subprogram  declaration  and  before 
any  subsequent  compilation  unit. 

•  These  pragmas  can  be  used  for  subprograms  declared  with  a  re¬ 
naming  declaration.  The  internal  name  must  be  a  simple  name,  and 
the  renaming  declaration  must  occur  in  the  same  declarative  part 
or  package  specification  as  the  pragma.  The  renamed  subprogram 
must  also  occur  in  that  same  declarative  part  or  package  specifica¬ 
tion.  Renamed  subprograms  that  occur  outside  the  declarative  part 
or  package  specification  are  ignored  (without  a  warning  diagnostic). 

•  None  of  these  pragmas  can  be  used  for  a  generic  subprogram  or 
a  generic  subprogram  instantiation.  In  particular,  they  caimot  be 
used  for  a  subprogram  that  is  declared  by  a  generic  instantiation  of 
a  predefined  subprogram  (such  as  UNCHECKED_CONVERSION). 
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Examples: 

In  this  example,  the  pragma  INTERFACE  identifies  SQRT  as  an  external 
subprogram;  the  language  name  argument  ASSEMBLE  has  no  effect. 
The  pragma  IMPORT.FUNCTION  uses  positional  notation  to  specify 
arguments  for  importing  the  declared  function  SQRT.  The  pragma  form 
indicates  that  the  internal  name  is  SQRT,  and  the  external  designator  is 
'MTHSSQRT”.  The  parameter  is  of  type  FLOAT,  and  is  passed  in  FPl; 
the  result  is  of  type  FLOAT,  and  it  is  returned  in  FP2. 


funetloB  SQRT  (X  :  FLOAT  )  raturn  FLOAT; 
pragma  INTERFACE  (ASSEMBLER,  SQRT ) ; 
pragma  IMPORT_FUNCTION 

(iQRT,  ■MTHSSQRT",  (FLOAT), 
FLOAT,  (VALUE(FP1 ) ) ,  VALUE (FP2) 
); 


The  next  example  shows  an  alternative  way  of  importing  the  declared 
function  SQRT  using  named  notation.  In  this  case,  the  parameter  is 
passed  in  FP5,  and  the  result  is  returned  in  FP4;  the  registers  which  are 
preserved  by  the  called  function  are  also  specified. 


fuaetloa  SQRT  (X  t  LONG_FLOAT  )  ratura  LONG_FLOAT; 
pragma  INTERFACE  (ASSEhQLER,  SQRT); 

pragma  IMPORT_FUNCTION  (INTERNAL  ->  SQRT, 

PARAMETER_TYPES  ->  ( LONG_FLOAT ) , 

RESULT_TYPE  ->  LONG_FLOAT , 

MECHANISM  ->  ( VALUE ( FP5 )) , 

RESULT_MECHANISM  ->  VALUE ( FP4 ) , 

EXTERNAL  ->  "MTHSDSQRT" , 

PRESERVED_REGISTERS  -> 

(DO,  Dl,  D2,  D3,  D4, 

AO,  Al,  A2,  A3,  A4, 

FPO,  FPl,  FP2,  FP3, 


D5,  D6,  D7, 

AS, 

EPS,  FP6)); 


If  the  previous  example  is  combined  with  the  code  in  the  first  example 
(that  is,  with  only  one  occurrence  of  pragma  INTERFACE),  the  result  is 
an  overloading  of  SQRT: 
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(uBCttoB  SORT  (X  I  LONG_FLOAT  )  raturB  LONG_FLOAT: 
fuBCtloa  SORT  (X  :  FLOAT  )  raturn  FLOAT; 
pragaa  INTERFACE  (ASSEMBLER,  SQRT); 
pragsa  I MPORT_ FUNCTION  (SQRT, 

•MTHSSQRT", 

( FLOAT ) , 

FLOAT, 

(VALUE( FPl ) )  , 

VALUE (FP2) ); 

pragma  IMPORT_FUNCTION  (INTERNAL 

PARAMBTER_TyPES 
RESULT_TYPE 
MECHANISM 
RESULT_MECHAN I SM 
EXTERNAL 
PRESERVED_REGISTERS  -> 

(DO,  Dl,  D2,  D3,  D4,  D5,  D6,  D7 , 

AO,  AI,  A2,  A3,  A4,  AS, 

FPO,  FPl,  FP2,  FP3,  FP5,  FP6 ) ) ; 

The  next  example  shows  the  use  of  renaming  with  an  imported  pro¬ 
cedure  (it  is  assumed  that  these  declarations  occur  in  a  declarative 
part  or  package  specification).  Note  that  the  renaming  causes  the  im¬ 
ported  ASSEMBLER  procedure  to  be  used  in  calls  to  both  procedures 
CHANGE  and  EXCHANGE.  Also  note  that  because  no  external  desig¬ 
nator  is  specified,  the  builder  global  symbol  associated  with  the  external 
subprogram  is  EXCHANGE,  and  because  no  parameter  mechanisms 
are  specified,  the  compiler's  defaults  will  apply  in  calls  to  CHANGE  or 
EXCHANGE. 

proCBdurB  CHANGE  (X,Y  t  INTEGER); 

precBdurc  EXCHANGE  (X,Y  :  INTEGER)  tbbbms  CHANGE; 

pragma  INTERFACE  (ASSEMBLER,  EXCHANGE); 

pragma  IHPORT_PROCBDURe  (INTERNAL  ••>  EXCHANGE, 

PARAMETER_TYPES  ->  ( INTEGER, INTEGER) ) ; 


->  SQRT, 

->  (LONG_FLOAT) , 
->  LONG_FLOAT, 

->  (VALUE (FP5) ) , 
->  VALUE(FP4) , 

»>  -MTHSDSQRT", 


13.9a.1.2  Exporting  Subprograms 

XD  Ada  provides  two  pragmas  for  exporting  subprograms: 
EXPORT.FUNCnON  and  EXPORT.PROCEDURE.  Both  export  prag¬ 
mas  establish  an  external  name  for  a  subprogram  and  make  the  name 
available  to  the  XD  Ada  Builder  as  a  global  symbol,  so  that  the  subpro¬ 
gram  can  be  called  by  an  assembly  language  module. 

The  EXPORT.FUNCnON  and  EXPORT.PROCEDURE  pragmas  allow 
the  export  of  the  kind  of  subprograms  indicated. 
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The  pragmas  for  exporting  subprograms  have  the  following  form; 

pragaa  EXPORT_FUNCTION  |  EXPORT_PROCEDURE 

(  [  INTERNAL  «> )  internal_njune 

[,  [EXTERNAL  => )  external_designator  ) 

[,  [  PARAMETER_TYPES  =•> )  (  paraineter_types  )  ] 

(,  [RESULT_TYPB  -> )  type_mark  )  —  FUNCTION  only 

[,  [MECHANISM  •>)  mechanism  ) 

[,  [RESULT  MECHANISM  •> )  mechanism  spec  )  —  FUNCTION  only 

)!  ~ 

parameter_types 

null  I  type_mark  {,  type_mark) 

mechanism  t  s- 

mechaniBm_8pec  |  (  mechani8m_spec  (,  mechani8m_spec)  ) 
mechanism_Bpec 

mechani8m_name  (  (  [REGISTER  ->  ]  regiBter_name  )  ] 
mechaniBm_name  tt- 

value”  I 

REFERENCE  j  BIT_REFERENCE  ] 

IXDPE_VECTOR  |  BIt”dOPE_VECTOR 

regiBterB  t:- 

aull  I  register_name  (,  reqiBter_name  } 

parameter_type8  jj- 

aull  I  type_mark  (,  type_mark) 

Functions  must  be  identified  by  their  intenuil  names  and  parameter 
and  result  types.  The  parameter  and  result  types  can  be  omitted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  types 
must  be  speciBed. 

Procedures  must  be  identified  by  their  internal  names  and  parameter 
types.  The  parameter  types  can  be  omitted  only  if  there  is  exactly 
one  procedure  of  that  name  in  the  same  declarative  part  or  package 
specification.  Otherwise,  the  parameter  types  must  be  specified. 

The  external  designator  denotes  an  XD  Ada  Builder  global  symbol 
that  is  associated  with  the  external  subprogram.  If  no  external  name  is 
given,  the  internal  name  is  used  as  the  global  symbol. 

The  parameter  types  option  specifies  a  series  of  one  or  more  type 
marks  (type  or  subtype  names),  not  parameter  names.  Each  type  mark 
is  positionally  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicated  by  the 
reserved  word  null. 
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The  result  type  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 

The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine.  Mechanism  options  and  possible 
values  for  mechanism  names  and  class  names  are  described  in  Section 
13.9a.l.l. 

If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
name  without  parentheses),  all  parameters  are  passed  using  that  mech¬ 
anism.  If  the  second  form  is  given  (a  series  of  mecharusm  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  parameter  in  the  saune  position  in  the  subprogram 
specification  will  be  passed.  With  the  second  form,  each  parameter 
i\ame  must  have  an  associated  mechanism  name. 

The  result  mechanism  option  is  used  only  for  functions;  it  specifies 
the  parameter-passing  mechanism  for  passing  the  result  type,  and 
optionally,  a  specific  register  used  to  pass  the  result. 

In  addition  to  the  rules  given  in  Section  13.9a,  the  rules  for  exporting 
subprograms  are  as  follows: 

•  An  exported  subprogram  must  be  a  library  unit  or  be  declared  in 
the  outermost  declarative  part  of  a  library  package.  Thus,  pragmas 
for  exporting  subprograms  are  allowed  only  in  the  following  cases: 

—  For  a  subprogram  specification  or  a  subprogram  body  that  is  a 
library  unit 

—  For  a  subprogram  specification  that  is  declared  in  the  outermost 
declarations  of  a  package  specification  or  a  package  body  that  is 
a  library  unit 

—  For  a  subprogram  body  that  is  declared  in  the  outermost  decla¬ 
rations  of  a  package  body  that  is  a  library  unit 

Consequently,  an  export  pragma  for  a  subprogram  body  is  allowed 
only  if  either  the  body  does  not  have  a  corresponding  specification, 
or  the  specification  and  body  occur  in  the  same  declarative  part. 

This  set  of  rules  implies  that  an  EXP0RT_FUNCT10N  or 
EXPORT_PROCEDURE  pragma  cannot  be  given  for  a  generic  li¬ 
brary  subprogram,  nor  can  one  be  given  for  a  subprogram  declared 
in  a  generic  library  package.  However,  either  of  these  pragmas 
can  be  given  for  a  subprogram  resulting  from  the  instantiation  of 
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a  generic  subprogram,  provided  that  the  instantiation  otherwise 
satisfies  this  set  of  rules. 

•  In  the  case  of  a  subprogram  declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the  subprogram  declaration  and  before 
any  subsequent  compilation  unit. 

•  Neither  of  these  pragmas  can  be  used  for  a  subprogram  that  is 
declared  with  a  renaming  declaration. 

•  Neither  of  these  pragmas  can  be  used  for  a  subprogram  that  is 
declared  by  a  generic  instantiation  of  a  built-in  library  subprogram 
(such  as  UNCHECKED_CONVERSION). 

Examples: 

The  following  example  shows  an  export  pragma  that  causes  the  Ada 
procedure  PROC  to  be  exported  for  use  in  an  assembly  language 
module.  The  name  PROC  is  declared  as  an  XD  Ada  Builder  global 
symbol. 

preeadur*  PROC  (Y  :  INTEGER); 
prapaa  EXPORT_PROCEDURE  ( PROC ) ; 

The  next  example  shows  an  Ada  function  being  called  from  an  assembly 
language  module: 

fuaetioa  MULTIPLY  (Y  :  la  INTEGER)  raturn  INTEGER  la 

ba«la 

ratun  Y  *  10; 

aad; 

pragM  EXPORT_rUNCTION  (  INTERNAL  ->  MULTIPLY, 

PARAMETER_TYPES  ->  (INTEGER), 

RESULT_TYPE  ->  INTEGER  ) ; 

pragaa  CALL_SEQUENCE_FUNCTION  ) 

UNIT  •>  MULTIPLY, 

PAftAMBTER_ TYPES  ->  (INTEGER), 

MEOiANISM  ->  (VALUE(DO)), 

RBSULT_MECHANISM  ->  VALUE(DO)); 


TITLE  •MC6e020  Calling  Ada" 
MODULE  •CALL_ADA* 

XDEF  CALL_ADA 
XRBF  MULTIPLY 

DSEG 

A  BLKB  4  1  An  INTEGER 

PSEG 
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CALL  ADA 


MOVE . L 

11, A  ! 

!  A  I-  1; 

MOVE . L 

A,  DO 

JSR 

MULT I PLY. L 

MOVE.L 

RTS 

DO,  A  1 

1  A  5=  MULTIPLY( 

END 

13.9a. 2  Importing  and  Exporting  Objects 

XD  Ada  provides  two  pragmas  for  importing  and  exporting  objects: 
IMPORT.OBJECT  and  EXPORT.OBJECT.  The  IMPORT.OBJECT 
pragma  references  storage  declared  in  an  assembly  language  module, 
^e  EXPORT.OBJECT  pragma  allows  an  assembly  language  module  to 
refer  to  the  storage  allocated  for  an  Ada  object. 

In  addition  to  the  rules  given  in  Section  13.9a,  the  rules  for  importing 
and  exporting  objects  are  as  follows: 

•  The  object  to  be  imported  or  exported  must  be  a  variable  declared 
by  an  object  declaration  at  the  outermost  level  of  a  library  package 
specification  or  body. 

•  The  subtype  indication  of  an  object  to  be  imported  or  exported  must 
denote  one  of  the  following: 

—  A  scalar  type  or  subtype. 

—  An  array  subtype  with  static  index  constraints  whose  component 
size  is  static. 

—  A  record  type  or  subtype  that  does  not  have  a  variant  part  and 
in  which  any  constraint  for  each  component  and  subcomponent 
is  static  (a  simple  record  type  or  subtj^e). 

•  Import  and  export  pragmas  are  not  allowed  for  objects  declared 
with  a  renaming  declaration. 

•  Import  and  export  pragmas  for  objects  are  not  allowed  in  a  generic 
unit. 
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Notes: 


Objects  of  private  or  limited  private  types  cannot  be  imported  or 
exported  outside  the  package  that  declares  the  (limited)  private  type. 
They  can  be  imported  or  exported  inside  the  body  of  the  package  where 
the  type  is  declared  (that  is,  where  the  full  type  is  known). 

The  XD  Ada  pragmas  for  importing  or  exporting  objects  can  precede  or 
follow  a  pragma  VOLATILE  for  the  same  objects  (see  Section  9.11). 

Address  clauses  are  not  allowed  in  combination  with  any  of  the  XD  Ada 
pragmas  for  importing  or  exporting  objects.  If  used  in  such  cases,  the 
pragma  involved  is  ignored  (see  Section  13.5). 


13.9a.2.1  Importing  Objects 

The  XD  Ada  IMPORT_OBJECT  pragma  specifies  that  the  storage  allo¬ 
cated  for  the  object  (when  the  assembly  language  module  is  compiled) 
be  made  known  to  the  calling  Ada  program  by  an  externally-defined  XD 
Ada  Builder  global  symbol. 

Pragma  IMPORT_OBJECT  has  the  following  form: 

pragma  IMPORT_OBJECT 

(  internal_naine  (,  external_deBignator  ]  ) 

The  internal  name  is  the  object  identifier.  The  external  designator 
denotes  an  XD  Ada  Builder  global  symbol  that  is  associated  with  the 
external  object.  If  no  external  designator  is  given,  the  internal  name  is 
used  as  the  global  symbol. 

Because  it  is  not  created  by  an  Ada  elaboration,  an  imported  object 
cannot  have  an  initial  value.  Specifically,  this  restriction  means  that  the 
object  to  be  imported: 

•  Cannot  be  a  constant  (have  an  explicit  initial  value). 

•  Cannot  be  an  access  type  (which  has  a  default  initial  value  of  null). 

•  Cannot  be  a  record  type  that  has  discriminants  (which  are  always 
initialized)  or  components  with  default  initial  expressions. 

•  Caimot  be  an  object  of  a  task  type. 


13.9a.2.1  Importing  Objects 
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Example: 

PIC  INTEGER; 

pragaa  IHPORT_OBJECT  (PID,  "PROCESSSID" ) ; 

In  this  example,  the  variable  PID  refers  to  the  externally-defined  symbol 
PROCESSSID. 

Alternatively,  this  example  can  be  written  in  named  notation  as  follows: 

PID  1  INTEGER; 

pragaa  IMPORT_OBJECT  (INTERNAL  =>  PID, 

EXTERNAL  =>  "PROCESSSID"); 


13.9a.2.2  Exporting  Objects 

The  XD  Ada  pragma  EXPORT_OBJECT  specifies  that  the  storage  al¬ 
located  for  the  object  (when  the  Ada  program  is  compiled)  be  made 
known  to  assembly  language  modules  by  an  XD  Ada  Builder  global 
symbol. 

Pragma  EXPORT_OBJECT  has  the  following  form: 

prapaa  BXPORT_OBJECT 

( internal_name  (,  external_designator ) ) 

The  internal  name  is  the  object  identifier.  The  external  designator 
denotes  an  XD  Ada  Builder  global  symbol  that  is  associated  with  the 
external  object.  If  no  external  designator  is  given,  the  internal  name  is 
used  as  the  global  symbol. 

Example: 

PIDi  INTEGER; 

pragaa  EXPORT_OBJECT  (PID,  "PROCESSSID"); 

Alternatively,  this  example  can  be  written  in  named  notation: 

PIDl  INTEGER) 

pragaa  EXPORT_OBJECT  (INTERNAL  •>  PID, 

EXTERNAL  ->  "PROCESSSID"); 
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13. 9a. 3  Importing  and  Exporting  Exceptions 

XD  Ada  provides  the  IMPORT.EXCEPTION  and  EXPORT.EXCEPTION 
pragmas  for  importing  and  exporting  exceptions.  The  pragma  IMPORT. 
EXCEPTION  allows  non-Ada  exceptions  to  be  used  in  Ada  programs; 
the  pragma  EXPORT.EXCEPTION  allows  Ada  exceptions  to  be  used  by 
foreign  units. 

The  rules  for  importing  and  exporting  exceptions  are  given  in  Section 
13.9a. 

Note: 

A  pragma  for  an  exception  that  is  declared  in  a  package  specification  is 
not  allowed  in  the  package  body. 


13.9a.3.1  Importing  Exceptions 

The  XD  Ada  IMPORT.EXCEPTION  pragma  is  provided  for  compatibil¬ 
ity  with  VAX  Ada.  This  pragma  specifies  that  the  exception  associated 
with  an  exception  declaration  in  an  Ada  program  be  defined  externally 
in  non- Ada  code. 

In  XD  Ada  pragma  IMPORT.EXCEPTION  has  the  following  form; 

pragma  IMPORT.EXCEPTION 

( internal.name  (,  external.designator ) 

( ,  ( FORM  ->  J  ADA  ) ) ; 

The  internal  name  must  be  an  Ada  identifier  that  denotes  a  declared 
exception.  The  external  designator  denotes  an  XD  Ada  Builder  global 
symbol  to  be  used  to  refer  to  the  exception.  If  no  extenud  name  is 
given,  the  internal  name  is  used  as  the  global  symbol. 

For  compatibility  with  VAX  Ada,  the  form  option  indicates  that  an  Ada 
exception  is  being  imported.  If  omitted,  this  defaults  to  ADA. 

The  external  desigruitor  refers  to  an  address  that  identifies  the  excep¬ 
tion. 

The  VAX  Ada  version  of  this  pragma  supports  an  alternative  form 
(VMS),  and  a  code  option  in  addition  to  the  XD  Ada  arguments.  If 
either  of  these  unsupported  arguments  is  specified,  the  compiler  ignores 
the  pragma  and  issues  a  warning  message. 


Importing  Exceptions  13.9a.3.l 
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13. 9a. 3. 2  Exporting  Exceptions 

The  XD  Ada  EXPORT_EXCEPTION  pragma  allows  Ada  exceptions  to 
be  visible  outside  the  XD  Ada  program,  so  that  they  can  be  raised  and 
handled  by  programs  written  in  XD  Ada  MC68020  assembly  language. 
This  pragma  establishes  an  external  name  for  an  Ada  exception  and 
makes  the  name  available  to  the  XD  Ada  Builder  as  a  global  symbol. 
Refer  to  the  XD  Ada  MC68020  Run-Time  Reference  Manual  for  further 
information  on  exporting  exceptions. 

Pragma  EXPORT_EXCEPTlON  has  the  following  form: 

praflaa  EXPORT_EXCEPTtON 

(  internal_naine  (,  external_designator  ] 

( ,  [ FORM  -> 1  ADA  ) ) ; 

The  intenud  name  must  be  an  Ada  identifier  that  denotes  a  declared 
exception.  The  external  designator  denotes  an  XD  Ada  Builder  global 
symbol  to  be  used  to  refer  to  the  exception. 

The  form  option  specifies  that  an  Ada  exception  is  being  exported. 

Example: 

UNDERFLOW  i  axcaptioB 

prapaa  EXPORT_EXCEPTION  (UNDERFLOW,  MTH_UNDBRFLOW,  ADA); 

In  this  example,  an  Ada  exception  is  exported  as  a  global  symbol. 
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Exporting  Exceptions 


13.10  Unchecked  Programming 


13.10.1  Unchecked  Storage  Deallocation 

The  following  information  supplements  the  Notes  section; 

Because  UNCHECKED_DEALLOCATION  is  a  predefined  generic  pro¬ 
cedure,  XD  Ada  does  not  allow  the  use  of  the  IMPORT_PROCEDURE 
pragma  to  substitute  an  alternative  procedure  body. 


13.10.2  Unchecked  Type  Conversions 

The  following  information  supplements  paragraph  2: 

XD  Ada  supports  the  generic  function  UNCHECKED_CONVERSION 
with  the  following  restrictions  on  the  class  of  types  involved: 

•  The  actual  subtype  corresponding  to  the  formal  type  TARGET  must 
not  be  an  unconstrained  array  type. 

•  The  actual  subtype  corresponding  to  the  formal  type  TARGET  must 
not  be  an  unconstrained  tj^e  with  discriminants. 

Further,  when  the  target  type  is  a  type  with  discriminants,  the  value 
resulting  from  a  call  of  the  conversion  hmction  resulting  from  an  instan¬ 
tiation  of  UNCHECKED_CONVERSION  is  checked  to  ensure  that  the 
discriminants  satisfy  the  constraints  of  the  actual  subtype. 

The  effect  with  XD  Ada  is  as  if  the  source  value  is  copied  one  byte 
in  ascending  order  of  address,  into  the  destination,  also  in  ascending 
order  of  address.  If  the  destination  has  fewer  bytes  than  the  source 
value,  the  high  order  bytes  of  the  source  value  are  ignored  (truncated). 
If  the  source  value  has  fewer  bytes  than  the  destination,  the  high  order 
bytes  of  the  destination  are  set  to  zero. 


13.10.2  Unchecked  Type  Conversions 
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Predefined  Language  Pragmas 


This  chapter  supplies  details  of  three  pragmas  introduced  by  XD  Ada 
MC68020  Version  1.2,  pragma  DIRECT_INTERRIJPT_ENTRY,  pragma 
IDENT  and  pragma  TIME.SLICE.  XD  Ada  pragmas  in  addition  to  those 
defined  in  Annex  B  of  the  Reference  Manual  for  the  AdaProgramming 
Language  (CALL.SEQUENCE  FUNCTION,  CALL  SEQUENCE 
PROCEDURE,  LEVEL,  UNK_0PT10N  and  TITLE)  are  described  in 
the  XD  Ada  MC68020  Supplement  to  the  Ada  Language  Reference  Manual  for 
Version  1.0. 

Oafinitions 

IDENT 

Takes  a  string  literal  of  31  or  fewer  characters  as  the  single  argument. 
The  pragma  IDENT  has  the  following  form: 

pr««aa  IDBNT  (string^literal ) ; 

This  pragma  is  allowed  only  in  the  outermost  declarative  part  of  a 
compilation  unit.  The  given  string  is  used  to  identify  the  object  module 
associated  with  the  compilation  unit  in  which  the  pragnta  IDENT  occurs. 

Summary 

Pragma  Meaning 

DIRECT_INTERRUFT_ENTRY  Takes  tlm  simple  name  of  an  interrupt 

entry,  \^>.h  must  have  no  parameters, 
as  the  single  argument.  This  pragma 
signals  to  the  compiler  that  the  interrupt 
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entry  is  to  be  directly  connected  to  the 
hardware  interrupt  (see  Section  13.5.1). 

Takes  a  static  expression  of  the  prede¬ 
fined  fixed  point  type  DURATKDN  (in 
Package  STANDARD)  as  the  single  ar¬ 
gument.  This  pragma  is  only  allowed 
in  the  outermost  declarative  part  of  a 
library  subprogram,  and  at  most  one 
such  pragma  is  allowed  in  a  library  sub¬ 
program.  It  has  an  effect  only  when 
the  subprogram  to  which  it  applies  is 
used  as  a  nnain  program.  This  pragma 
specifies  the  nominal  amount  of  elapsed 
time  permitted  for  the  execution  of  a  task 
when  other  tasks  of  the  same  priority  are 
also  eligible  for  execution.  A  positive, 
nonzero  value  of  the  static  expression 
eiuibles  scheduling  for  all  tasks  in  the 
subprogram;  a  negative  or  zero  value 
disables  it  (see  Section  9.8a). 
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In  addition  to  the  standard  predefined  pragnxas,  described  in  Annex  B 
of  the  Reference  Manual  for  the  Ada  Programming  Language,  XD  Ada  sup¬ 
ports  pragmas  CALL  SEQUENCE  FUNCTION,  CALL.SEQUENCE 
PROCEDURE,  UNK.OPTION,  and  TITLE,  which  are  defined  here. 
This  annex  also  summarizes  the  definitions  given  elsewhere  of  the 
remaining  implementation-defined  pragmas. 

Definitions 

CALL  SEQUENCE  FUNCTION 
CALL.SEQUENCE.PROCEDURE 

The  pragma  CALL_SEQUENCE_PROCEDURE  is  used  for  describing 
machine  code  insertions  or  exported  subprograms.  It  specifies  how 
parameters  are  mapped  onto  registers,  and  which  registers  must  be 
preserved,  for  machine  code  insertions  (see  Section  13.8).  The  pragma 
CALL_SEQUENCE_FUNCnON  is  also  provided.  These  pragmas  have 
the  form: 

pr«gM  CALL_SEQUENCB_FUNCTrON 

([  [UNIT  »>J  internal_name 
(,  (RES0LT_TYPE  ->]  t^e_marX  ] 

(,  ( PARAMETER_TYPES  •> )  T  parajneter_type8  )  ) 
t,  iMECHANlSM~»>)  mechaniam  ) 

[,  [RESULT_MECHANISM  -> )  mechaniBm_Bpec  ) 

(,  (PRESER^D  REGISTERS  ->  J  (  reglatera  )  ) 

); 

praflsa  CALL_SEQUeNCE_PROCEDURE 

([  [UNIT  “>J  internal_naine 
(,  ( PARAMETER_TYPES  ->)  (  paranieter_typeB  )  ) 

(,  [MECHANISH  -> )  mechanlBin  ) 

I,  |PRESERVED_REGISTERS  ->  J  (  regiBterB  )  ] 

); 
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paraineter_types 

null  I  type_roark  {,  type_mark) 
mechanism  :i” 

mechanism_8pec  |  (  mechanism_spec  (,  mechanism_Bpec )  ) 
mechaniEm_8pec  !:=* 

mechanism_name  (  (  (REGISTER  ->  ]  regiBter_name  )  ] 
mechaniBm_name  i:- 

value”  I 

REFERENCE  j  BIT_RBFERENCE  | 

DOPE_VECTOR  j  B1t2dOPE_VECTOR 

registers  i:- 

null  I  regi8ter_naine  (,  regi8ter_naine  ) 

Functions  must  be  identified  by  their  internal  names  and  parameter 
and  result  types.  The  parameter  and  result  types  can  be  omitted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  types 
must  be  specified. 

Procedures  must  be  identified  by  their  internal  names  and  parameter 
types.  The  parameter  types  can  be  omitted  only  if  there  is  exactly 
one  procedure  of  that  luime  in  the  same  declarative  part  or  package 
specification.  Otherwise,  the  parameter  types  must  be  specified. 

The  parameter  types  option  specifies  a  series  of  one  or  more  type 
marks  (type  or  subtype  names),  not  parameter  names.  Each  type  mark 
is  positionally  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicated  by  the 
reserved  word  null. 

The  result  t5rpe  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 

The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine. 

If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
luune  without  parentheses),  all  parameters  are  passed  using  that  mech- 
aiusm.  If  the  second  form  is  given  (a  series  of  mechanism  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  parameter  in  the  same  position  in  the  subprogram 
specification  will  be  passed.  With  the  second  form,  each  parameter 
name  must  have  an  associated  mechanism  name. 
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The  result  mechanism  option  is  used  only  for  functions;  it  specifies  the 
parameter-passing  mechanism  for  passing  the  result  type. 

Mechanism  names  are  described  in  Section  13. 9a. 1.1. 

The  preserved  registers  option  gives  a  list  of  hardware  registers  which 
are  not  altered  by  the  procedure  or  function.  If  this  option  is  omitted  it 
implies  that  no  registers  are  preserved;  in  this  case  the  effect  is  one  of 
the  following: 

•  If  the  body  of  the  subprogram  is  written  in  Ada,  the  compiler 
calculates  which  registers  are  preserved 

•  If  the  body  of  the  subprogram  is  a  machine  code  insertion,  the 
pragma  has  the  same  effect  as  pragma  IMPORT_PROCEDURE 


UNK.OPTION 

This  pragma  is  used  to  associate  link  option  file  names  with  a  program. 
Link  option  files  are  used  to  specify  the  target  and  mapping  definitions 
to  be  used  when  building  the  program.  In  this  way,  they  do  not  have 
to  be  explicitly  defined  on  the  XDACS  LINK  command  line.  The 
appropriate  external  target  and  mapping  definitions  (in  the  form  of  link 
option  files)  are  entered  into  the  program  library  by  use  of  the  XDACS 
command  COPY  LINK.OPTION/FOREIGN,  as  described  in  Deivloping 
XD  Ada  Programs  on  VMS  Systems  for  the  MC68020.  If  a  suitable  link 
option  file  exists  in  another  program  library,  it  can  be  copied  to  the 
current  program  library  with  the  XDACS  command  COPY  LINK_ 
OPTION.  The  advantage  of  using  link  option  files  is  that  the  program 
definition  is  separate  from  the  program  itself,  and  so  can  be  altered 
without  making  the  last  compile  obsolete.  The  LINK_OPTION  pragma 
therefore  removes  the  need  to  recompile  the  whole  program.  More 
detail  on  this  topic  can  be  found  in  Sections  7.9  and  8.10  of  Developing 
XD  Ada  Programs  on  VMS  Systems  for  the  MC68020. 

Pragma  LINK_0PT10N  has  the  form; 

pr««M  LINK_OPTION(  ( 

(  (TARGiT->llink-option-f ile-name) 
i ,  [MaPPING->)link-option-f ile-name) 

I); 

This  pragma  is  only  allowed  in  the  outermost  declarative  part  of  a 
subprogram  that  is  a  library  unit;  at  most  one  such  pragma  is  allowed 
in  a  subprogram.  If  it  occurs  in  a  subprogram  other  than  the  main 
orogram,  this  pragma  has  no  effect  (see  Sections  9.8  and  9.9  (LRM)). 
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TITLE 


Takes  a  title  or  a  subtitle  string,  or  both,  in  either  order,  as  arguments. 

Pragma  TITLE  has  the  form; 

pragma  TITLE  (titling-option 
[ ,  titling-option ) ) ; 

titling-option  :« 

[TITLE  ->)  strlng_literal 
I  [SUBTITLE  “>)  8tring_literal 

This  pragma  is  allowed  anywhere  a  pragma  is  allowed;  the  given  strings 

supersede  the  default  title  or  subtitle  portions  of  a  compilation  listing. 

Summary 

Pragma  Meaning 

EXPORT_EXCEPTION  Takes  an  internal  name  denoting  an 

exception,  and  optioiudly  takes  an 
external  designator  (the  name  of  an 
XD  Ada  Builder  global  symbol),  and 
a  form  (ADA)  as  arguments,  l^is 
pragma  is  only  allowed  at  the  place 
of  a  declarative  item,  and  must  apply 
to  an  exception  declared  by  an  earlier 
declarative  item  of  the  same  declara¬ 
tive  part  or  package  specification.  The 
pragma  permits  an  Ada  exception  to 
be  handled  by  programs  written  in  XD 
Ada  MC68020  assembly  language  (see 
Section  13. 9a. 3.2). 

EXPORT.FUNCnON  Takes  an  internal  name  denoting  a 

function,  and  optionally  takes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  parameter 
types,  and  result  type  as  arguments. 

TMs  pragma  is  only  allowed  at  the  place 
of  a  declarative  item,  and  must  apply 
to  a  function  declared  by  an  earlier 
declarative  item  of  the  same  declara¬ 
tive  part  or  package  specification.  In 
the  case  of  a  function  declared  as  a 
compilation  imit,  the  pragma  is  only 
allowed  after  the  function  declaration 
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EXPORT.OBJECT 


EXPORT.PROCEDURE 


and  before  any  subsequent  compilation 
unit.  This  pragma  is  not  allowed  for  a 
function  declared  with  a  renaming  dec¬ 
laration,  and  is  not  allowed  for  a  generic 
function  (it  can  be  given  for  a  generic 
instantiation).  This  pragma  permits  an 
Ada  function  to  be  called  from  a  pro¬ 
gram  written  in  assembly  language  (see 
Section  13. 9a. 1.2). 

Takes  an  internal  name  denoting  an 
object,  and  optionally  takes  an  exter¬ 
nal  designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  and  size  des¬ 
ignator  as  arguments.  This  pragma  is 
only  allowed  at  the  place  of  a  declarative 
item  at  the  outermost  level  of  a  library 
package  specification  or  body,  and  must 
apply  to  a  variable  declared  by  an  earlier 
declarative  item  of  the  same  package 
specification  or  body;  the  variable  must 
be  of  a  type  or  subtype  that  has  a  con¬ 
stant  size  at  compile  time.  This  pragma 
is  not  allowed  for  objects  declared  with  a 
renaming  declaration,  and  is  not  allowed 
in  a  generic  unit.  This  pragma  permits 
an  Ada  object  to  be  referred  to  by  a 
routine  written  in  assembly  language  (see 
Section  13.9a.2.2). 

Takes  an  internal  name  denoting  a  pro¬ 
cedure,  and  optionally  takes  an  external 
designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  and  parameter 
types  as  arguments.  This  pragma  is  only 
allowed  at  the  place  of  a  declarative  item, 
and  must  apply  to  a  procedure  declared 
by  an  earlier  declarative  item  of  the  same 
declarative  part  or  package  specification. 
In  the  case  of  a  procedure  declared  as 
a  compilation  unit,  the  pragma  is  only 
allowed  after  the  procedure  declaration 
and  before  any  subsequent  compilation 
unit.  This  pragma  is  not  allowed  for 
a  procedure  declared  with  a  renaming 
declaration,  and  is  not  allowed  for  a 
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generic  procedure  (if  may  be  given  for 
a  generic  instantiation).  This  pragma 
permits  an  Ada  routine  to  be  called  from 
a  program  written  in  assembly  language 
(see  Section  13. 9a. 1.2). 

lMPORT_EXCEPTION  Takes  an  internal  name  denoting  an 

exception,  and  optionally  takes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  and  a  form 
(ADA)  as  arguments.  This  pragma  is 
only  allowed  at  the  place  of  a  declarative 
item,  and  must  apply  to  an  exception 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  package 
specification.  The  pragma  is  included  for 
compatibility  with  VAX  Ada  (see  Section 
13.9a.3.1). 

IMPORT_FUNCnON  Takes  an  internal  name  denoting  a  func¬ 

tion,  and  optionally  takes  an  external 
designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  parameter  types, 
and  result  type  as  argrunents.  Pragma 
INTERFACE  must  be  used  with  this 
pragma  (see  Section  13.9).  This  pragma 
is  only  allowed  at  the  place  of  a  declar¬ 
ative  item,  and  must  apply  to  a  function 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  package 
specification.  In  the  case  of  a  func¬ 
tion  declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the  function 
declaration  and  before  any  subsequent 
compilation  unit.  This  pragma  is  allowed 
for  a  function  declared  with  a  renaming 
declaration;  it  is  not  allowed  for  a  generic 
function  or  a  generic  function  instantia¬ 
tion.  This  pragma  permits  an  assembly 
language  routine  to  be  used  as  an  Ada 
function  (see  Section  13. 9a. 1.1). 
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IMPORT.OBJECT 


IMPORT_PROCEDURE 


Takes  an  internal  name  denoting  an 
object,  and  optionally  takes  an  external 
designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  as  arguments. 
This  pragma  is  only  allowed  at  the  place 
of  a  declarative  item  at  the  outermost 
level  of  a  library  package  specification 
or  body,  and  must  apply  to  a  variable 
declared  by  an  earlier  declarative  item  of 
the  same  package  specification  or  body; 
the  variable  must  be  of  a  type  or  subtype 
that  has  a  constant  size  at  compile  time. 
This  pragma  is  not  allowed  for  objects 
declared  with  a  renaming  declaration, 
and  is  not  allowed  in  a  generic  unit.  This 
pragma  permits  storage  declared  in  an 
assembly  language  routine  to  be  referred 
to  by  an  Ada  program  (see  Section 
13.9a.2.1). 

Takes  an  internal  name  denoting  a 
procedure,  and  optionally  takes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  and  pa¬ 
rameter  types  as  arguments.  Pragma 
INTERFA(ZE  must  be  used  with  this 
pragma  (see  Section  13.9).  This  pragma 
is  only  allowed  at  the  place  of  a  declara¬ 
tive  item,  and  must  apply  to  a  procedure 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  pack¬ 
age  specification.  In  the  case  of  a 
procedure  declared  as  a  compilation 
unit,  the  pragma  is  only  allowed  after 
the  procedure  declaration  and  before 
any  subsequent  compilation  unit.  This 
pragma  is  allowed  for  a  procedure  de¬ 
clared  with  a  renaming  declaration;  it  is 
not  allowed  for  a  generic  procedure  or 
a  generic  procedure  instantiation.  This 
pragma  permits  an  assembly  language 
routine  to  be  used  as  an  Ada  procedure 
(see  Section  13.9a.  1.1). 
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INTERFACE 

LEVEL 

STORAGE.UNIT 
SUPPRESS.  ALL 

VOLATILE 


In  XD  Ada,  pragma  INTERFACE  is 
required  in  combination  with  pragmas 
IMPORT.FUNCTION  and  IMPORT. 
PROCEDURE  (see  Section  13.9a. 1). 

This  pragma  identifies  a  task  or  task  type 
as  running  at  interrupt  level.  Pragma 
LEVEL  has  one  argument  specifying 
the  level  for  its  interrupts  (see  Section 
13.5.1). 

In  XD  Ada.  the  only  argument  allowed 
for  this  pragma  is  8. 

This  pragma  has  no  argument  and  is 
only  allowed  following  a  compilation 
unit.  This  pragma  specifies  that  all  run¬ 
time  checks  in  the  unit  are  suppressed 
(see  Section  11.7). 

Takes  the  simple  name  of  a  variable 
as  the  single  argument.  This  pragma 
is  only  allowed  for  a  variable  declared 
by  an  object  declaration.  The  variable 
declaration  and  the  pragma  must  both 
occur  (in  this  order)  immediately  within 
the  same  declarative  part  or  package 
specification.  The  pragma  must  appear 
before  any  occurrence  of  the  name  of 
the  variable  other  than  in  an  address 
clause  or  in  one  of  the  XD  Ada  pragmas 
IMPORT.OBJECT  or  EXPORT.OBJECTT. 
The  variable  cannot  be  declared  by  a 
renaming  declaration.  The  VOLATILE 
pragma  specifies  that  the  variable  may  be 
modified  asynchronously.  This  pragnui 
instructs  the  compiler  to  obtain  the  value 
of  a  variable  from  memory  each  time  it 
is  used  (see  Section  9.11). 
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